This is part 7 of a series, previous posts: part 1, 2, 3, 4, 5 and 6
In the previous part I promised to talk about how to update a program while it's running, if you were hoping for some cool file system locking trick you are going to be disappointed.
The method I used for yaTimer, the time tracking application I've developed, is very simple. All the program files are not stored directly in the program folder but in a sub-folder this sub-folder is different for each version, so what you get is:
1.1.0 all the files for version 1.1.0
And then after upgrading to version 1.2:
1.1.0 the old files from version 1.1.0
1.2 the new files for version 1.2
In the yaTimer folder we place aprogram called yaTimer.exe – but this is not the real program it's just a stub that will run the real yaTimer.exe from the current version sub-folder, how does it know what the current version is? It's stored in the registry, if you don't like using the registry you can add a small configuration file to the application folder.
Now we have it all, we can update the application while it's running (because the update process actually writes to a different folder) and if we ever have to revert an update we need to change just one registry value. We just have to add one small feature, after the update the application should offer to restart itself – and by restarting I mean execute the stub program that will run the new version.
And what about updating the service itself? We can't stop the service in order to replace files during the update, a service runs in what is called a "job object" when you stop a service all programs that were executed by that service (like our update program) are terminated automatically, but the workaround is easy, the update program just has to add a new service for our newer version and start it, the new service should then stop and uninstall the old service.
In the next (and last) post in the series we will talk about alternatives to writing your own auto-update.
posted @ Thursday, August 2, 2007 11:20 AM