Because software updates and patches are released daily, keeping a system current is a daunting task. Microsoft has suggested solving this problem by automatically updating software without user input. But no matter how you feel about this approach, you have probably faced the same technical problem. Updating a custom application is a complex operation for the best programmers, and beyond the reach of many. Thankfully, the Updater Application Block (UAB) brings software updating into the realm of possibility and reality.
The UAB is available from the MSDN Patterns and Practices site. After you install the package, you must build/compile the project. If you are using Visual Studio, you must add a reference to the created DLL (or simply copy the DLL to the bin directory of the project in which you intend to use it). Finally, you must reference the assembly in your code, like this:
The download includes plenty of samples as well. Before running the included samples, you must run the setup script—referenced in the Start Menu item for the UAB. This script builds the various solutions and sets permissions, virtual directories, and shares. If your development workstation is not adequately protected, double-check security after running the script. Also, it establishes paths in the manifest files, which are used to point the client applications to the updates, as we’ll see.
Although setting up UAB is time consuming, implementation and running the block in your application is surprisingly straightforward:
- The manifest is the sole responsibility of the server in this operation. It is a document that points the pulling software to the correct locations within the file share. The Manifest Utility creates this file.
- A control application on the client handles starting and stopping the update process. It uses a configuration file with a custom download and validation protocol to handle the actual collection of remote files.
- The update process implements the configuration defined by the controller, first downloading and then validating the remote files.
- To update the application in question (if necessary), you have a post-processor definition space.
As with most of the Application Blocks, the UAB provides both out-of-the-box functionality and a set of interfaces allowing you to write custom tools. The standard tools are sufficient for many updating tasks.
The server-level configuration is encapsulated in a manifest, which is an XML file that lets the user know where to get the updated files for download. The UAB includes an application that assists with the creation of a manifest, both in a windows forms format and a command line (see Figure A). This application creates an XML file that is used by the client control application.
Creating the manifest file
The configuration from the user perspective is contained in the app.config file. A number of sections in the file must be added in an UpdaterConfiguration node, including the location of the downloader and validator component, the applications to be updated, polling times, and log file location.
Aside from the configuration of the UAB, asynchronous block execution is surprisingly simple. When you're ready to update the application in question, the StartUpdater() method starts the process. When you're ready to stop—after a time limit, or on close, or whatever, you use StopUpdater().
You may be wondering about a self-updating application, such as configuration files that you want to update overnight. For this situation, a Windows service that implements the UAB suffices. For operating-system style applications, a good example is included with the download that uses a separate thread to control the application.
Custom controllers, downloaders, validators, and post processors are the pieces that bring advanced functionality to the UAB. Complexity increases considerably when advancing from out-of-the-box functionality to the custom components.
The controller component consumes the provided ApplicationUpdateManager and exposes the StartUpdater and StopUpdater methods. Since the controller reads a configuration file to determine its path, a custom updating solution might not require a custom controller. The ApplicationUpdateManager API is handy when integrating the controller with the application itself.
Custom downloaders are necessary when the transfer mechanism provided with the initial install doesn’t work. The downloader component derives from the provided IDownloader interface, which provides synchronous and asynchronous functions for downloading. FTP, SOAP, UNC paths, and other protocols for file downloads may be coded into new downloaders.
Like controllers, validators most likely won’t need to be customized. The RSAValidator and KeyValidator that are included in the box are sufficient for most applications. Nonetheless, the IValidator interface is provided in case you need to use a proprietary validation technique.
Finally, the post processor provides the most possibilities. This control defines what happens to the downloaded files after download and will make self-updating applications possible. The post processor components derive from the IPostProcessor interface but primarily use that interface to access the manifest as needed. The code in the post processor is not directly associated with the updater itself but is instead focused on running the installer, writing to the registry, or logging results.
Another great tool
The UAB provides fantastic and easy-to-use out-of-the-box functionality, with complete customization thrown into the bargain. For Windows forms applications, this is the way to move updates around.