Is it possible for a running c# application to start/invoke some new arbitrary process, but only do so after the current running application is terminated?
I guess it's possible to call the new process from Process.Start() via cmd.exe and do something like sleep 3 & c:\mynewapplication.exe - this would giver the 'caller' some three seconds to terminate itself.
However this is a bit hacky, and was wondering if there was a neater way?
Depending on the type of application, you could simply listen to the end of the program. One option you have is the Application.ApplicationExit event.
Another possibility is to start another process, that waits until the first process dies. You could poll Process.GetProcesses for example. This will raise the event, even if the first process crashes. You could also register the Process.Exited event.
It has little to do with C#. It is a question about the Windows OS, and, in particular, in WinAPI.
Generally, the only 'thing' that runs code is threads. When your process in terminated, all its threads die.
Your best approach is probably by starting a process that will wait before starting your new process, as you suggested, however you may, for example, hook on some of the functions called when something happens and start your new process there.
Related
So I have a background program that starts with Windows, minimized to system tray icon. Once it loads I need it to constantly start checking if a process has started (for example VLC). Once the process has started, It must wait for it to close in order to start doing stuff and then get back to check if it has started. I've been trying to do this for a while now, but I just can't figure out how.
How would I constantly check if a program has started?
One way would be to have the Background Deamon look for aprogramm of a specific name. Unfortunately this not overly reliable (due to name overlaps), would require a lot of polling and runs the risk of race conditions (the process starting when your deamon is still working).
What would be reliable, is if it is the Deamon that actually starts the foreground process. That way it could do work before Process.Start() and after Process.WaitForExit(), with full information when both states happen: https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process?view=netcore-3.1
Steam is a good example. It is a single-instance process, so any further requests can be relayed to the running instance. The desktop links to programms/games are actually weblinks - not programm links. Those links use the :steam protocoll, wich is associated with the steam processes. So it goes like this:
user klicks on a WebLink with :steam procotoll
Windows resolves to hand this into a commandline call to the steam programm
A instance is started with the proper order in via commandline. Single instancing will not allow a 2nd instanc to start, but hand the request over a already running one
the already or now suddenly running instance calls the programm, having full data on when it starts and ends - being the actuall logical caller
I have a code like this:
ProcessStartInfo psi= new ProcessStartInfo(...);
Process process = Process.Start(psi);
Application.Current.Shutdown();
even so the process have the process information of the application (i have logs) in rare cases on the production computer the process is not opened at all.
As I now Process.Start() is synchronous and if it returns a value there must be a running process.
Another information that I have is that the genuine process is also the shell process.
Does anyone have an idea what is the problem?
Process is IO artifact, so there are always some delays, between you start it and it actually opened.
This delay, naturally, depends on concrete machine, where you run your code.
So, like a solution you can
or sleep main thread untill the p process opened, for some amount of time
or close the main thread, only when from (say) some timer you are able to find required p process in the list of already run OS processes.
The second, I think, is a better solution.
I have a programm that runs another one (lets call the first app Stater and the second app - Worker).
I use
process.start();
process.waiForExit();
process.Close();
in Starter.
But if Starter is forced to close while waiting for Worker (for some extern reason) Worker will be still in processes, blocking files, eating memory etc.
So, I want to check if Worker is already running before I will try to start it.
I've tried Process.GetProcessesByName("worker.exe") but no luck (even if I can see Worker in Task Manager).
I've seen some topics here about checking every process in memory for its modules, but still I already know the running file I hope to avoid such solution.
Any advices?
The reason you cannot find it is because you're using .exe. If the executable shows up as worker.exe in TaskManager, just call:
Process[] workers = Process.GetProcessesByName("worker")
foreach (Process worker in workers)
{
worker.Kill();
worker.WaitForExit();
worker.Dispose();
}
At the time of starting Worker process, save its ID in your application's configuration/setting file, in this way when you will launch your Starter process, it will first load that ID from settings file and will check if that process is currently running or not. If you want to immediately close Worker process, you can call process.Kill() on it.
This is much easier...
System.Diagnostics.Process.Start("cmd.exe","/c taskkill /IM notepad.exe");
This code will close the Notepad (if it is running). Type the program name you want to close with it's extension (.exe).
Some applications cannot be stopped without forcing.
Use /F after taskkill to force the action.
If you want to close the process tree use /T after program name.
System.Diagnostics.Process.Start("cmd.exe","/c taskkill /F /IM notepad.exe /T");
When you call GetProcessesByName("worker") you don't specify exe extension as explained in MSDN
And if you wish to keep a global variable with the process object that you have started you could simply use the process.Kill();
If you only need to detect that "worker" is running, a technically much superior solution is have it lock a global mutex for the duration of its lifetime. Any process that knows the mutex name (which is under your control) can then see if the mutex is locked (if it is, worker is running).
However this is not easy to implement correctly as there are many little details you want to get just right; even then, there might be a race condition of "starter" and "worker" are actually launched simultaneously etc (of course this problem, and many others, also apply to all other solutions so it cannot be considered a drawback).
I'm working on a console app that kicks off a fairly long running process (2-3 minutes). What options are available for displaying progress, or even just writing a "." to screen every few seconds so the user knows the app hasn't stopped responding?
You have (at least) 3 ways to do this:
Simplest: On program start, set a global variable to false, then start a thread that writes a dot to the console, Thread.Sleep()s a second, repeats until the variable is set to true. On your main thread do your work, when finished set the variable to true and then Join() the other thread.
Still simple: Add another global variable to the mix, type int. In your worker thread increase it, whenever some progress is made, on the console writer thread reduce interval to say 250ms, but draw a dot only if progress counter has changed. This gives an idea of how fast your app progresses
A bit advanced: Create a boolean as in first step plus an AutoResetEvent, let the console writer thread repeatedly wait on the event, when app makes progress Set() the event. When finished set boolean to true and Set() again before Join()ing. The advanced part in this is to know, in what portions to report progress.
The simplest approach is if your application has an incremental loop then you could put a simple full stop on the the console. Not nice, but it does give an indication of "I'm alive".
But that approach can result in too much info (too many characters going to console) or too few as your hooking into a bit of the code that does not really have that responsibility.
So, perhaps a nicer way that you can reuse is to create a console user class that is run in a thread with a 1 second tick. It can use backspacing and the good old | / | / - sequence to give the impression of something rotating. It can also check for key presses to allow the user to exit.
Another option, depending on the nature of your users, is to use a logging framework like NLog. That way your implementation is UI independent and you can see what is happening in more or less detail at run time in the console, from another machine, whatever.
Is there any good way to handle a forced exit in C#?
I have a formless C# application that talks to an LCD over serial. Once the application is running, the only way to kill it is with task manager. The trouble with this is that the program needs to turn the LCD off when it is done, and it doesn't look as if my Application.ApplicationExit event is ever fired in this condition.
Any ideas?
Once the application is running, the only way to kill it is with task manager.
My big idea would be to change this.
Stick an icon in the notification area that the user can use to shut your app down properly, or set it up so that running the app again will instead shut down an already-running instance if one exists, or any other way that sounds like a good idea.
Requiring a user to use Task Manager to shut down your application screams poor design.
Write a code in your program loop (with a timer perhaps) to read a file or a registry key. For example if a file at C:\YOURPROGRAM\CLOSEME contains text "closeme", close your program gracefully. Write another program that write that C:\YOURPROGRAM\CLOSEME file. So, whenever you want to shutdown your program, don't use taskmanager, instead, open second program.
Some options:
Write a separate process with a GUI that can start and stop the main process. For example, when you install the Apache web server on Windows the server itself is installed as a service. It can be started and stopped from the system services management panel, but it also comes with a "monitor" process that sits in the notification area, tells you whether Apache is running and lets you start or stop it manually.
If it's acceptable for your use-case, make the application a console application. You can register a handler for when the user presses CTRL+C (see Console.CancelKeyPress) that performs your cleanup before your process exits. This still won't let you handle someone killing the process from Task Manager, but it's very easy to do and might be good enough depending on your situation.