We Keep Coding

Run current Process in background C#

I have a C# VS2017 Console App. I'd like the CMD prompt to return immediately after executing while the App runs in the background (it's a long running process).
Currently I'm starting the App as a Process from another executable just to do this by setting Process.StartInfo properties.
Is there an opposite to Process.WaitForExit() that can be set at the start of a program?
I read somewhere using a WinForms App without the form might work, yet I tried to delete the form and sleep for 10 seconds, showing a MessageBox after (in Main). The program returned and showed the box immediately without sleeping.

Check if Windows Application is running (not process)

I am hoping to check at the beginning of an automated test if an application is open. I can check if the process is running by doing the following
foreach (Process proc in Process.GetProcesses())
{
if (proc.ProcessName.Contains(name))
{
return true;
}
}
However, the process I want to find starts up about a minute before the application actually opens and is ready to be used by the test methods (its a very slow starting application). The above code sample looks at all windows processes running, but I am wondering, is there a way to do a similar method but to look at windows applications running?

There is a method already in class Process that you can use to check if an app with a UI has fully started:
Process.WaitForInputIdle(int milliseconds)
This will wait up to milliseconds ms for the message loop to become idle (and returns a bool to indicate success status). Depending on the application you're waiting for, you might want to allow 30 seconds or longer.
This might work for you, but be aware that in my experience for some applications it is not totally reliable!
The Windows API documentation has more details about the Windows API function that WaitForInputIdle() calls behind the scenes.

When a process is started, you can say application has started.
What you want is to wait until application startup progress has completed or not.
This means, when process is started, application startup begins. When application startup is completed, is becomes ready for user input. So I think you should have a look at following question and its answers.
Programmatically, how does this application detect that a program is ready for input

Apllication is proces.
If you can modify app, at app start you can create file and at end delete it. So you can chceck file existance. If file exist app starting/started.
If you need info when main form is created use:
WINFORMS
Form.Shown event.
WPF Loaded Event

uITestControl.Exists did the trick for me.
This method will return a boolean value corresponding to the existence of the application window being open. This allows an if statement to be created that can open the application if not already open, or do nothing if its already open.

How to kill Mono program properly

I'm currently working on a cross-platform app written in C#. I have a huge problem with testing and debugging it under Linux/Mono. When my application hangs due to an error, I have to kill the process (either using stop button in MonoDevelop debugger or using kill(all) command). The problem is, that after killing I cannot start the application again. When restarted from console, it waits a second or two and exits, showing nothing as output. When started from MonoDevelop, debugger loads some assemblies and then the process exits with no error. There seems to be no Mono-related service in process table. The only way to start the application again is to log off and log in again.
What I'm doing wrong?

C# App using Windows API Code Pack Shell Extension won't shut down

I have a C# application which makes use of the Microsoft Windows API Code Pack - in particular the Shell Extensions, which I use to monitor storage devices and media insertion and removal.
However when I attempt to close the app in Visual C# 2010 (Express) I then have to manually stop the debugger. It appears that there is a background loop in the Win API Code Pack that is still running, even when I manually dispose of the ShellObjectWatcher. The only way I can kill it is to manually stop the debugger.
The app is built in WPF.
Eventually, VisC#2010 gives up on trying to run the app under the debugger. You tell it to start debugging and it just doesn't. Only way to get it going again is to kill the app using Task Manager and then shutdown VC#2010 - go have a coffee - then start it up again. Odd. I suspect there is a hidden process or window hanging around which isn't being shut down when I try and clean up the app.
Any idea how I can clean up this ShellObjectWatcher a little more effectively?

To fix the bug in the Code Pack Shell project, add one line in MessageListener.WndProc()​:
case (uint)WindowMessage.Destr​oy:
**_running = false;**
break;
Now ThreadMethod() will exit the message loop.

OK using System.Environment.Exit(0); fixes this issue. App shuts down and the debugger releases control. Brute force works in this case.

I bumped into the same issue, but solved it by setting the thread as a background thread (meaning, it is killed when the application stops):
in MessageListener.cs, in the constructor, at line 40, I have:
_windowThread = new Thread(ThreadMethod);
// The line below will force the thread to terminate when the app exits.
_windowThread.IsBackground = true;
_windowThread.SetApartmentState(ApartmentState.STA);

Exiting a C# winforms application

I have an application that imports data from Excel. However, when I run the winforms app and I intrupt the application, using System.Windows.Forms.Application.Exit(); I can still see the "MyAppName".vshost32.exe running in task manager.
When I exit the application in debug mode, the form closes, but the VS IDE is not "stopped".
How do I ensure the application ends correctly.

Your call to Application.Exit() is working fine. The MyAppName.vshost32.exe executable is a host for debugging purposes. It runs whilst you have a project open in Visual Studio, regardless of if there is an active debugging session.
Update: Ok, I misunderstood. The above is true, but you're probably having problems with hung threads in the background. You need to terminate your threads to make it close properly. Asher's answer covers this. If you're just trying to do a super-hacky quick-and-dirty kill, you can use the following (though I take no responsibility for side effects, since it's extremely hacky):
System.Diagnostics.Process.GetCurrentProcess().Kill();

The process doesn't terminate because it still has foreground threads running.
If you create threads in your application you need to mark them as background threads or make sure they terminate when you want the application to exit.

Have you tried the more brutal Environment.Exit() function?
Application.Exit() just sends a message saying to shutdown; if the message never gets processed (for whatever reason), the application will stay running indefinitely.
From the MSDN documentation of Application.Exit():
The Exit method stops all running message loops on all threads and closes all windows of the application. This method does not necessarily force the application to exit. The Exit method is typically called from within a message loop, and forces Run to return.

I had a similar problem caused by a third party tool that did not allow me to set the threads as Background. Polynomial had the right idea, but then syntax is like this:
System.Diagnostics.Process.GetCurrentProcess().Kill();