September 2012

Expand Update Possibilities with Manual Versioning

AppLife Update identifies the existence of an update through the use of versioning. The update controller deployed out there on client systems knows the current version that is installed and, after performing an update check, knows the update packages that have been published for the current version. With this information, the process can continue. Most commonly, a deployed client’s current version is determined by the .Net Assembly Version stamp of the host .Net executable. Using an assembly version, the current version is readily available, and when the host executable is replaced, presumably the replacement executable has a new higher assembly version. The AppLife Update solution makes it very easy to use the .Net Assembly Version stamp in a very hands-off way, making it the most common scenario. It is not the only method available though, and looking at versioning a little differently opens up many possibilities.

What’s Possible with Custom Versioning

The thing about using an Assembly Version stamp is that the executable must be rebuilt in order to create an update. There are circumstances where it is favorable to be able to update an application installation without rebuilding the primary executable. Sometimes what you might want to update isn’t even an application at all. AppLife Update can be used to package and automatically deploy updates to all kinds of application sub-systems, such as reporting templates, map files, and other types of document repositories. The ease with which you can package any information, as well as a code process to execute, into an update package and the flexibility available to implement a simple check, retrieve, and apply process using an AppLife Update Controller makes it possible to be very creative with updating application components independently. Versioning is key to any update process using AppLife Update, so here is a simple and effective method for versioning just about any type of update process.

Xml File Versioning

The basic idea behind Xml File Versioning is to place a simple Xml file on the client PC that holds a version stamp. We’ll read that version stamp from the file and set the Update Controller version based on the content so that we can publish updates that target a specific version. Within the update, we’ll use an Xml Update Action to modify that version file contents so that after the update is executed, the version file will then represent a newer version based on the modifications that the update made.

Note: We will use a stand-alone Xml file, however applications that utilize a .config already have an Xml file readily available for versioning sub-components. Adding a new appSettings value to an existing .config file can accomplish the same result.

We’ll need a snippet of Xml to hold a version stamp. A file like this will do just fine:

Filename: Version.Xml

<?xml version=”1.0″ encoding=”utf-8″?>
<currentVersion value=”″ />

Read the Current Version and Setup the Controller

To setup an Update Controller for manual versioning, ensure the UseHostAssemblyVersion property is set to false. With that set, your code can set the Version property based on the content of the Version.Xml file.

1:  private Version getCurrentVersion() {  
2:   Version currentVersion = null;  
3:    using(XmlReader reader = XmlReader.Create("Version.Xml")) {  
4:     reader.ReadToFollowing("currentVersion");  
5:     string versionStr = reader.GetAttribute("value");  
6:     if(!string.IsNullOrEmpty(versionStr)) {  
7:      currentVersion = new Version(versionStr);  
8:     }  
9:    }  
10:   return currentVersion;  
11:  }  

With the version set, you can call CheckForUpdate or CheckForUpdateAsync on the Update Controller and find updates for the current client version.

Applying Updates without Shutting Down the Host Application

When updating sub-systems, it is often not necessary as well as undesirable to shut down the host application. If the update will operate on files that are not locked, or can be unlocked without shutting down the application, your sub-system updating process can operate seamlessly by using a few of the options that are available when applying an update. To accomplish this, pass in a parameter to the ApplyUpdate method. The following options will apply an update without shutting down, without showing an update window (silently), and the method call will wait for the update to complete (synchronously). Any combination of these options can be used.

1:  mUpdateController.ApplyUpdate  
2:  (ApplyUpdateOptions.NoShutdown | ApplyUpdateOptions.NoUpdateWindow |  
3:   ApplyUpdateOptions.WaitForCompletion);  
Updating the Version.Xml file during an Update

Maintaining the Version.Xml file is very easy and once we set it up, we can forget about it. Each update will modify the version file based on the update version that is being executed. We can accomplish this by adding two update actions to the update action list.

  1. Use a Set Shared Property update action to access the current update version value and assign it to a Shared Property.
  2. Use a Change Xml Node update action to modify the Version.Xml file on the client to match the current update version.

Action 1

Action 2

That’s it. Precede these two actions with the update actions that perform the necessary work on the client and proceed to publish updates that your application can find and seamlessly apply. An Update Controller and manual versioning opens the door for many creative updating scenarios utilizing the power and flexibility of the AppLife Update engine.

Application Update Customization using Custom Data

When publishing updates for applications, it is often helpful to implement rules that can be applied on an update-by-update basis. With AppLife Update, the custom data field provides this opportunity.


With each update, you can specify a custom data string to go with the update. This value is then available to your application after an update check has been performed. Your application can interrogate the value and control additional logic based on the information. As an example, when creating updates for AppLife Update, we use this field to know whether or not the update requires Visual Studio to be closed. If it does, we add a RequiresVSClosed property to the custom data field.


Accessing the Custom Data in Your Application

After an update check, the update controller has a CurrentUpdate property that holds an UpdateInformation object. This object has a CustomData property that holds, you guessed it, the Custom Data string that you specify when publishing the update.

Code Snippet

if(updateController1.CheckForUpdate()) {

string customData =updateController1.CurrentUpdate.CustomData;



Changing Custom Data after Publication

Custom Data can be modified after an update has been published without having to re-build the update package itself. To modify custom data, you can Manage Published Updates…

From the Manage Published Updates dialog the Custom Data string can be modified and then published.


A Class to Parse Name/Value Pairs

A common approach to be able to provide multiple pieces of information through the custom data string is to use a name/value pair syntax, and then extract this information within your application code. To help with this, here is a class that will parse a custom data field using a name=value; syntax.

AppUpdateCustomData.cs and AppUpdateCustomData.vb

Using this class, you can easily extract and use multi-value custom data strings in your applications.


Using the AppUpdateCustomData class:

Code Snippet

1:  if(updateController1.CheckForUpdate()) {  
2:    Kjs.AppLife.Update.AppUpdateCustomData customData = newKjs.AppLife.Update.AppUpdateCustomData(updateController1.CurrentUpdate.CustomData);  
3:   string myValue1;  
4:   string myValue2;  
5:   if(customData.DataTable.ContainsKey("MyName1")) {  
6:  myValue1 = customData.DataTable["MyName1"];  
7:   }  
8:   if(customData.DataTable.ContainsKey("MyName2")) {  
9:   myValue2 = customData.DataTable["MyName2"];  
10:   }  
11:  }  

In conclusion, the Custom Data field provides the means for update publishers to assign information to individual update packages that applications can use to control application update behavior.

Scroll to Top