Frage

I've written a small C# console app that is used by many users on a shared storage server. It's runtime should always be < 3 seconds or so, and is run automatically in the background to assist another GUI app the user is really trying to use. Because of this, I want to make sure the program ALWAYS exits completely, no matter if it throws an error or what not.

In the Application_Startup, I have the basic structure of:

try
{
    // Calls real code here
}
catch
{
    // Log any errors (and the logging itself has a try with empty catch around it
    // so that there's no way it can causes problems)
}
finally
{
    Application.Shutdown();
}

I figured that with this structure, it was impossible for my app to become a zombie process. However, when trying to push new versions of this app, I repeatedly find that I cannot delete and replace the executable because the "file is in use", meaning that it's hanging on someone's computer out there, even though it should only run for a few seconds and always shutdown.

So, how is it that my app is seemingly becoming a hanging process on peoples' computers with the code structure I have? What am I missing?

Edit: Added "Application." to resolve ShutDown() for clarity.

War es hilfreich?

Lösung

There are two options here:

  1. Your console application doesn't really finish in 3 seconds, but rather takes a lot longer. You need to debug it and see what takes it that long.
  2. Your console application takes 3 seconds to exit, but it is run every minute by the GUI, and you have more than 40 users, so the probability of finding the executable unused are slim.

If it's the first one, and you don't want to debug it, you can always start a second thread, wait for 3 seconds and then kill the entire process.

Andere Tipps

Maybe the code inside the try block is still executing for at least one of the clients and is not really limited to 3s or so. To prevent such case, you would need multithreaded application - one thread for processing and one in the background killing the working thread after a timeout. Prior to that you should ask yourself if such infrastructure is really needed.

Another thing that comes to mind would be that one of the users had the application running right at the moment, probability depends on the number of your users.

Maybe designing your support app as a always running multithreaded service would be a much better idea instead of instantiating one running application for each client request.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top