So I wrote a VB.net project in Visual studio. I have a scheduled task that is set to run the program every morning at 10AM.
If I use windows explorer and double click the application, it runs fine.
If I open task scheduler, open the task properties, and browse to the application, then choose run, the program fails, due to Runtime exceptions.
I know I have the path entered correctly, since I can debug the instance when it crashes from the task scheduler. VS2010 pulls up my source code...
Any Ideas?
I feel like I've tried everything..
Update
The exception is System.IO.FileNotFoundException, remember, it works fine when I double click the app. If attach a debugger to the process after it is executed from the task scheduler, I can then restart the debugger, and Voila!, The application runs fine.
When you create a task, under the "Edit Action" properties, there is a field "Start In (Optional)" It is not optional. It is critical this is populated with the path to the program you are executing. if it is not your scheduled task will fail... It seems redundant but it fixes the issue.
Thanks Microsoft.
Related
I created a VB.net application that, among other things, uses two DLLs to update the firmware on a microprocessor. It works perfectly during debugging.
To distribute it, I used InstallShield LE to create an installer. If I install the program and run from the Start Menu or Desktop icon, the program works - except for that part that uses the DLLs... that fails part of the way through.
The kicker is that if I go to C:\Program Files (x86)\programName\ and run the .exe from there everything works perfectly.
When I run from the shortcuts or from the actual directory and go to Task Manager and view the process properties, it lists the same directory. So I am under the assumption that the shortcuts are properly referencing the correct location.
So, how can running from a shortcut affect the running of the .exe?!
Thank you for your help.
-Mschmidtbauer
I've got a Console application that is running an OWIN self hosted WebAPI service. When I run in in the Ubuntu command line every thing works fine however when I try and debug it in MonoDevelop, the main function just executes and then exits. I want it to remain debugging so I can make requests against the WebAPI but can seem to get it to not exit.
Is there something that I should be doing to make the debugger attach to the entire program?
How old is your MonoDevelop?
I just ran my MonoDevelop v5.11, and I can find the option "Attach to process" inside the "Run" menu. (This option was not present in prior versions, such as 4.0.x.)
I have a VStudio2012 solution for a Windows form app that has been compiled and runs fine for me when I launch it from myproject\bin\debug\utility.exe (the mainform comes up fine and the program runs fine).
I am trying to get a colleague familiar with the program and when he creates a shortcut to the above program and opens the utility.exe by doubleclicking it, then VStudio comes up instead of the mainform of the app.
Is there any way to achieve this without getting into some deployment scenario? I would like to leave this utility.exe where it is now and just get somebody else to run it from there? Is this possible?
Your friend is opening the .config file, not the .exe.
See "hide extensions for known file types"
I have a console application that dies very quickly, and upon inspecting the code, I can't tell exactly where it'll die (I've basically narrowed it down to a 10 line radius) so that I further debug it.
For reasons I won't go into, I can't execute the process from VS (I have the binaries, source, and pdbs though, but I can't build outside of the build server's environment), and would like to attach to the process... but when I start the process, it dies much sooner than I could ever hope to refresh the attach to process dialog.
Ideas?
One possibility for doing this is to use any existing Visual Studio project and specify the application as the application to debug. The steps (in Visual Studio 2010) are:
Go to the project properties.
Choose Debugging (under Configuration Properties)
Edit the Command and fill in the path to the binary
Then it should be possible just to start debugging (e.g., F5 or Debug\Start Debugging).
Another option that might be a bit quicker if you have the debugging tools installed would be to use WinDbg.exe. It would avoid needing to use a Visual Studio project. You can open the executable, specify command line parameters, etc. and then type g<ret> in the command line to fire it up.
My installer needs to open a file browse dialog. As there is no file browse dialog provided by WIX I have written a C# dll containing a method to invoke the standard OpenFileDialog when called by a Custom Action. However while this works fine in Win2003 the Custom Action just hangs when run on Windows 7. It seems to get as far as the ShowDialog() call then stop. As a test I have written a separate Windows Forms app with a single dialog and button to invoke the OpenFileDialog and, as expected, that works fine. I just can't get the OpenFileDialog to appear from within my msi!
I suspect it may be a security thing so I ran the installer from msiexec opened as Administrator but with no difference!
Does anyone have any ideas how to fix this?
Many Thanks.
// create a new thread with appropriate apartment state to launch UI
OpenFileDialog fileBrowser = new OpenFileDialog();
Thread worker = new Thread(fileBrowser.Show);
worker.SetApartmentState(ApartmentState.STA); // <-- here is the magic code
worker.Start();
worker.Join();
When I attempted this I found it was popping up behind the other MSI windows. Until I figured this out, it looked just like a hang.
For this and a whole heap of other reasons, I ended up writing a bespoke install mechanism and ditching MSI. Much friendlier on the user and their system in the end.