Using Process.Run() does not work as intended on a C# Console exe file.

[Frosty]

The title says it all. I have some code which does Process.Run() on another executable console file. The console file is set to a "Windows Application" so that it does not appear, and allows me to run other programs and functions periodically, all in the background.

while (true) {
    //code
}

When I open this code from the file by double clicking, it works perfectly fine, loops around, and performs all the functions as intended, however. Whenever I run this file by doing Process.Run(), it opens, does nothing, and then closes immediately afterwards.

 

[Skydiver]

How do you know it opened up if the program is marked as a Windows application so that it does not appear?

 

[Frosty]

How do you know it opened up if the program is marked as a Windows application so that it does not appear?

I know it opened because it shows up in the task manager for a few seconds then disappears

 

[Frosty]

The title says it all. I have some code which does Process.Run() on another executable console file. The console file is set to a "Windows Application" so that it does not appear, and allows me to run other programs and functions periodically, all in the background.

while (true) {
    //code
}

When I open this code from the file by double clicking, it works perfectly fine, loops around, and performs all the functions as intended, however. Whenever I run this file by doing Process.Run(), it opens, does nothing, and then closes immediately afterwards.

I just noticed that I mispoke anad wrote "Process.Run()" instead of "Process.Start()" which is the actual name of the function, sorry for any inconvenience.

 

[Skydiver]

I know it opened because it shows up in the task manager for a few seconds then disappears

In that case, then Process.Start() has succeeded in it's job of starting your console program. That is essentially all needs to do: call the OS level ShellExecute() either directly or indirectly to get your other program started.

It is not your job to debug your program to figure out why it's not working correctly under those conditions. You can either add more logging into your code to try to figure out why it is not doing what you were expecting it to do, or you could setup some debugging hooks so that you will have an opportunity to attach a debugger to the running process.

 

[Frosty]

In that case, then Process.Start() has succeeded in it's job of starting your console program. That is essentially all needs to do: call the OS level ShellExecute() either directly or indirectly to get your other program started.

It is not your job to debug your program to figure out why it's not working correctly under those conditions. You can either add more logging into your code to try to figure out why it is not doing what you were expecting it to do, or you could setup some debugging hooks so that you will have an opportunity to attach a debugger to the running process.

But it doesn't succeed in it's job at all. Whenever i double click to run the file, or debug it in my IDE, it does it's purpose, but whenever run by the Process.Start() method, it does not stay in the while true loop, and instead closes itself momentarily after, which is not what i want at all.

 

[Skydiver]

Process.Start() just tells the OS to start your program. You need to debug your program to determine why it is breaking out of the loop.

With you saying that Process.Start() that it's not doing it's job is like saying that catapult on an aircraft carrier is not doing it's job keeping aircraft flying in the air after take-off. All the catapult needs to do is to accelerate the plane up to its needed take-off speed. Staying in flight after take off is the job of the plane and it's pilot.

As I said previously, time to do some logging, or attach a debugger to the child process to figure out why it is exiting.

If you have some AV software running, make sure that it is configured to not consider one program launching another program as "suspicious behavior". A lot of modern AV software now is not just signature based, but also behavior based. My company has it's AV settings so tight that the AV thinks SQL Server Installer is doing something malicious when it is launching child programs to perform installation/configuration.

 

[jmcilhinney]

One thing to keep in mind is that, by default, an application started using Process.Start has the same current directory as the app that started it. If your second app assumes that its current directory is the program folder then it will fail to find files in that folder. This is a common error when people start games that way. If the app you're starting assumes a specific current directory then you need to specify that as the working directory when calling Process.Start, which you do using a ProcessStartInfo object.

This is just speculation though. As you have not shown us what you're actually doing in either app, all we can do is guess. That's not something that most of us like doing because it can lead to a lot of wasted time on our part and yours. As suggested, if the app starts then Process.Start is working. If you need to do something different in the first app when starting the second, you need to know why the second is failing and that means diagnosing the second app, not the first.