AppLife Update is a comprehensive automatic updating solution for Microsoft .Net applications. Designed for flexibility, AppLife Update provides many options for consideration. Implementing automatic, or merely automated, update functionality into an application inherently requires an implementer to consider just how the process should work for their users and their application. This guide serves to assist an implementer in planning automatic updating features for their applications using AppLife Update.

The AppLife Update solution consists of three primary components.

1. AppLife Update Controller API– This component and related API integrates into your application and provides the properties, methods, and events to programmatically create your update process.
2. AppLife Update Engine – The update engine provides an execution context for update actions. The Update Engine is the process that executes remotely and actually performs the tasks defined to update your deployed applications.
3. AppLife Make Update – Make Update is a windows application that allows you to create and publish update packages. By configuring update actions that will be executed by an update engine on your remote clients, you can define the steps to update your application from one version to the next.

This guide will focus on the AppLife Update Controller, and decisions related to how you configure your update process.

The primary questions that need to be answered are:

1. How am I going to version my application?
2. How do I want the user to interact with my update process?
3. Does the user have necessary permissions to update my application?
4. Where are my updates going to be hosted?
5. Are clients going to be behind proxy servers?

Secondary questions include:

1. Does my application need to do anything before an update, such as save state?
2. Are there any licensing restrictions?

In order to update an application, it is important to know what version is currently present. Updates are published targeting specific versions of software so that the update process can migrate that version to a higher version. Knowing what version we are allows us to find updates that we can apply.

There are many ways to version your software. The most obvious is to use the Assembly version or the File version stamp of the launching executable. Of course using this method requires the launching executable to be re-built for every version which might or might not be desirable. When deciding on a method to set the version stamp, consider what actions your updates will be required to perform. If you anticipate that the main (host) executable of your application will always be built and replaced with each update, then utilizing the host assembly version stamp is the best approach. However, if your application utilizes data files, help information, database information or other content that you might want to update without requiring a rebuild of the launching executable, then using the host assembly version might not be the best option. The AppLife Update Controller has a Version property that can be set at runtime. When updating the primary executable isn’t always desirable, a common approach is to read the version from a file in the application directory, such as a text file or even an app.config file. When this method is employed, the version stamp is read from the file and assigned to the Update Controllers version property. Your updates will then include an update action to either replace or update the version information file as the update executes.

To summarize, if it is anticipated that your primary executable will always be rebuilt and included as part of each update, use the assembly version of the host executable for client versioning. This is done by setting the UseHostAssemblyVersion property of the AppLife Update controller to true. If the host executable will not always be included in each update, use a local version stamp and set the Update Controller Version property at runtime to a value read from an updateable local store.

Segmented Application Updates

Wrapping up the notes on versioning, it’s worth mentioning that an application can be segmented and each segment updated independently. By utilizing a segment version stamp and a separate update location, you can easily publish updates for one segment separate from others. Your versioning strategy is an important part of accomplishing segmentation.

The update process determines how your users will interact with the action of checking for updates, downloading an update, and initiating the update execution. The AppLife Update controller provides a complete process with one method call. The built-in process will perform a check for updates, display the results of the check, then prompt the user to download and apply the update. This process, including the download, is performed modally, meaning the user cannot interact with your application during the process. Though this is the simplest process to implement it might not be the best fit for your application. If your updates are large or your client network connection is slow, downloading the update in the background would be a better approach. Using methods and events of the Update Controller, you can customize the process completely. Download progress is cached so that interrupted downloads can be resumed from where the previous session ended. Another benefit of caching is that you can download an update once, and postpone the application of the update until the next launch without needing to download the update again.

In order to perform any update activity on a remote client, the user executing your software must have privileges to perform the activity. In today’s threat filled Windows environment, you must assume that the user has only limited privileges. Organizations have started to lock down workstations as a means to combat the many threats to their networks. In addition, newer Microsoft operating systems utilize the User Account Control (UAC) technology which ensures even high privileged users run applications with limited security rights. Limited user privileges is the largest obstacle to automatically updating deployed applications. When considering user privileges and what actions to take, your choices are few. You can install your application to a location that a limited user can replace files. This is the approach that Microsoft Click Once employs. If you install your application per user, into a location in their user profile, users will have permissions to update your application files without any privilege elevation.

The standard application installation location on Windows is the Program Files directory. This directory requires elevated privileges in order to write files there, which means a limited user will not be able to update applications installed to the program files directory. It is possible to modify the directory permissions during installation to permit limited users to replace files. There are other options as well. You could choose to deploy the AppLife Update Windows Service. When deployed and your application registered with the service, updates to your application will be executed under the security context of the local system account, allowing you to replace files in the program files directory as well as other activities such as modifying the system registry. You can also elect to initiate a UAC prompt to achieve permissions elevation. This approach is appropriate if your users have higher privileges, but your application runs without elevation.

To control the permissions behavior, set the ElevationType property of the AppLife Update controller. Your choices are None, UAC, or Service. If you choose to utilize the AppLife Update Windows Service, you can use the Windows Installer merge module to deploy the service and register your application. Additional guidance is provided in the AppLife Update help system.

You can host your updates on any file server. You can use http, ftp, UNC or file shares. You can pass credentials during the request. You can utilize SSL. These decisions are based on your client distribution and what resource is available to you.

It is worth noting that you can check for and download updates using one protocol (such as http), and publish updates using a different protocol such as ftp.

After considering these questions you are ready to integrate AppLife Update into your application. Reviewing the documentation and quick starts will provide the technical details necessary to quickly integrate an update process.

Pre-shutdown Processing

If it is possible for multiple instances of your application to be running and the non-update initiating instances must perform any work prior to being shut down by the update process, you can utilize the built-in inter process communications of the update controller to listen for and handle the ShutdownRequested event. This mechanism allows you to prompt the user to save their work, close out any currently running processes etc. You can even cancel the update process from another instance.

Integrating Licensing

For applications that utilize licensing controls, you can intercede in the update discovery process and control what, if any, updates can be discovered based on local client information, such as licensing. By handling the UpdateFound event of the update controller you can control the availability of updates.

This guide discussed some of the questions that need to be considered when planning an integration of AppLife Update into an application. It is by no means exhaustive. AppLife Update is the most flexible application updating framework available for deployed .Net applications, and with that flexibility it is sometimes unclear where to start. By focusing on the questions posed in this guide you can quickly plan and integrate a secure, robust, and reliable updating feature into your .Net applications using AppLife Update.