Really. End Already

In my last post, I referred to the application I have been working on for some time.  It's a windows application, straight up, and does not use any of the click once features (a decision that we waited too late to address properly).  We found ourselves, therefore, needing a way to update the application in the wild without a manual un-install/install each time.  Additionally, we didn't want the users to have to do much to receive new bits from us.

I'll save the details of what we implemented for another post, but I wanted to touch on one part of the process.  It's pretty commonly known that if an assembly is loaded into a running process, the physical file is locked.  Therefore, it was impossible for us to update the assemblies on our client's machines without shutting down the application, first.  in my implementation, I created an instance of the Process class and used it to start up our application updater.  Then, I asked the main application to end, so the updater could refresh the assemblies it had locked.  Something like this...

Unfortunately, about every third time this code ran, on average, the application froze instead of exiting...keeping the assemblies locked and rendering the updater useless.  So, what to do.  First, I tried the sledgehammer approach of having the main application's thread sleep for a while before exiting.  This improved things a bit.  I saw one freeze out of every 4 or 5 attempts.  I reasoned that the application's main thread (only thread) must be in the middle of doing something when Application.Exit is being called and isn't handling the request well.  I found a nice comparison of Application.Exit, Environment.Exit and End here.  After reading it, I realized that the message pump may still have work on its queue when exit is being called.  I modified the above code to look like the following.