When you are developing a windows application, it is necessary to have an updater strategy built-in. We all know that enhancements and fixes are a part of the software development process. Best practices and frameworks exist for creating application updaters services, and integrating them in your windows application. Microsoft provides ClickOnce technology which makes it very easy to package your application so that it can easily updated whenever there is an update in the application. Another approach is the Updater Application Block (UAB) which is a bit more difficult to implement, but also offers a great deal more flexibility in what you can do with it.
One of our customers had a requirement which was slightly different from the standard update requirement. This customer offers a suite of applications (much like MS Office). There is a further twist, the business case for this customer is such that even within the same application, the end user might be able to run multiple versions of these applications side-by-side (like you can run Visual Studio 2005 and 2008 side by side). Each of these applications and the various active versions of a given application could have updates released independently of each other. One would think that all of these could be implemented as separate ClickOnce packages, but that would have been a maintenance nightmare on the update server, and also would have presented a very poor experience for the end user.
Problem statement – Create an updater solution which uses a single application to provide automatic update notifications for multiple applications, and manages download and installation for all of these updates.
Our solution was to create a utility application on the client end which acts more like an Application Manager. This application keeps track of all the applications installed on the client (and those that are not installed), and manages the updates and notifications for all of them. The solution mirrors the concept presented in the Microsoft UAB. Here is what it looks like:
The application manager can be implemented through a variety of paradigms. It can be a service which is always running in the background. It can be implemented as an application launcher – this means that to launch any of the applications in the suite, you first have to launch the application manager. There can be other ideas on how it can be implemented.
The basic solution for how it works is similar to the UAB. It keeps track of the currently installed application on the client machine (perhaps through reading registry settings). It keeps track if new releases by requesting a the server for a manifest file which contains information about the various versions of the applications present in the application suite – specifically, it contains information about the latest versions of the applications present on the update server, and information about how they can be accessed. The application manager then compares this information from the manifest to the local manifest that it maintains of the installed applications. The way this differs from the UAB is that in UAB, the manifest on the server contains metadata about the releases of a single application. In our scenario, it contains the information for multiple applications.
The application manager can provide various services such as provide notifications when updates are available, maintain user preferences for update notifications, download updates, install selective updates, or install updates automatically (or based on a schedule). All of these, and many other rich update features can be implemented through the use of the application manager.
On the server side, the process is simplified because whenever any of the applications are changed, a single change has to be made to a single manifest file/data source. For all updates, only one manifest needs to be managed, which makes update management easier and less error prone. The benefit of using an Updater Service (instead of simply requesting the file directly from the server) is that the manifest information can then be kept in a database, from where the service can generate the manifest file. Or another implementation could be that the manifest file is generated from a well-defined directory structure on the server. The point is that using an interface such as a service allows you to have more flexibility on how you implement your server. Another benefit could be to build-in licensing or role-based manifest generation (to prevent access to certain applications or updates).
Finally, the application manager itself needs to be updated. We chose to use ClickOnce for the Application Manager itself. The reason is the ease of deployment and update for a single application using ClickOnce is still the best. So, the use case for setting up new client machines becomes very simple. First install application manager to using ClickOnce. Then the application manager downloads and installs everything else.
