Once you have specified the auto-update requirements for your application you need to decide what will be the architecture of the auto-update solution. This post offers an overview of the most common options you might want to consider.
We assume in this series of articles that updating your application involves replacing part of the executable code among other things. The reason why you can’t do that directly from within your application’s process is that since Windows XP the OS doesn’t allow an executable file to be deleted (or replaced) while it is running. There are some techniques to bypass that limitation and you can still rename the locked file and come up with some clever way to restart the application from a different executable, but we are not going to talk about those here. Our focus is on methods that you can use to provide auto-update functionality without having to implement everything from scratch.
There are generally 3 common approaches to update your executable files based on which process initiates an update of your application:
- Using an installer process (like Windows Installer)
- Using a bootstrapper process (like ClickOnce)
- Using a service
1. Using an installer
In this approach your application initiates an external process to do the update and then terminates allowing that process to replace all the necessary files. The external process could be a custom executable which is part of the installation or more likely the Windows Installer itself.
Most applications that require a full installation would use this approach. It is probably the most flexible way to distribute an application and allows you to have finer control of when to check for an update and how to install it. Of course the extra flexibility comes at the cost of having to implement part of the update process inside the application itself, like checking for new versions and notifying the users. Luckily there are a few open source frameworks that handle some of that complexity for you. We will talk more about these in Part 4.
2. Using a bootstrapper*
A “bootstrapper” is a process that will always run before your application and will do all that is necessary to keep it updated, like check for latest versions and run a new installation. Once it has finished it’s tasks, it then executes the actual application.
There are 2 variations of the bootstrapper approach. One that you provide your custom bootstrapper with your installation and one that you use a system-wide bootstrapper service like ClickOnce.
The first, where you provide a custom bootstrapper, is similar to the custom installer that we mentioned above. You need to implement all the logic for updating the application and come up with a mechanism to update the bootstrapper itself. Again you have the full control of the whole update process, however this is beyond the scope of these articles.
In the next post we will go through the second variation and in particular the use of ClickOnce which is probably the easiest way for C# developers to implement auto-updates as it provides a complete solution “out of the box”. ClickOnce will always run before your application and take care of it’s auto-update requirements as they are specified in the deployment manifest without having to add a single line of code to the executable. Of course there are some limitations but for most cases, especially for enterprise software and applications that are going to be distributed only within the same organisation, ClickOnce is the logical first choice.
3. Using a service
In certain scenarios you might want to consider using a service that will monitor the current installation and check for updates periodically or when triggered by specified events. The benefit of the service is that it can keep your application updated even if it has not been used by the user for a while. It is also useful in cases where you don’t want to invoke a check for updates when the application is executed for performance or other reasons and you need the update process to be completely decoupled.
Again, this method requires a complete custom solution and we are not going to discuss about it in any further detail here.
Which approach is better?
There is no right answer to this question, it depends on the requirements of your specific application. In most common scenarios however it is likely that you will have to chose between 1 and 2, an installer or a bootstrapper. If you can narrow down your options between Windows Installer and ClickOnce then it is worth going through this article provided by Microsoft first, before you make your decision.
In the following posts we will go through those two solutions, starting with the simpler one which is ClickOnce.
< Part 1 Part 3 >
* (Note: We use the term bootstrapper liberally to describe the whole process that precedes the execution of our application in order to check for updates and thus prepare the application to run. Not to be confused with the Bootstrapper Packages that are used by ClickOnce to describe the prerequisites of an application before installation, or setup.exe which is used as the bootstrapper of a ClickOnce installation, by installing those prerequisites.)