The AppLife Update Blog

A complete solution for maintaining deployed software on the Windows platform

  • Deploying and Maintaining Applications using the AppLife Manager

    So, here’s my scenario. I have multiple software products that my teams are developing and I’ll be deploying and maintaining these products on many deployed Windows-based computers. And once deployed, my teams will be continuing development and adding features, frequently needing to update those deployed installations. Can you relate to my scenario? If so, read on…

    The AppLife Update Deployed Application Maintenance Solution


    Introducing AppLife Manager

    The AppLife Manager is a Windows Service and accompanying System Tray based User Interface that installs on a Windows Client PC and connects to one or more AppLife Servers. Once connected, the AppLife Manager will discover new applications that are configured to target that individual client and automatically install update packages for those applications.


    No integration within the application’s source code is required.

    AppLife Manager ships with AppLife Server and is available with AppLife Cloud subscriptions. By downloading and installing AppLife Server (or starting a Hosted AppLife Update subscription), you’ll have at your disposal an instant application deployment and maintenance system.

    So, let’s get started with a little demonstration. I’ll go in reverse and demonstrate the end-result first, then cover the steps on how to get there.

    Deployment with AppLife Manager

    Step 1 – Install AppLife Manager.

    I’m using the server at, so I can get AppLife Manager with the following link:

    This link downloads an msi that I need to install. This requires admin privileges. Once installed, I get this little gem in my System Tray.


    And Clicking on that, opens the AppLife Manger window.


    There’s not much to see yet, but once we add our server it’ll get a little more interesting. So, let’s do that.

    Step 2 – Register an AppLife Server.

    Servers can be added by clicking on the Add Server button.


    Adding a server requires administrative privileges, and a UAC prompt will be presented. Enter the server URL and a Client Access Key. This Client Access Key is important and is used on the AppLife Server dashboard to target which clients will have access to applications and updates.


    When we finish adding the server, something interesting happens. Any applications that target the designated Client Access Key will be automatically downloaded and installed. In this case, there is only one application (AppLife Sketch).

    clip_image008 clip_image010 clip_image012

    A link was added to my start menu as part of the update that performs the installation, but I can also launch the application directly from AppLife Manager by clicking the Start Application Button.


    Now that AppLife Manager is managing AppLife Sketch, it will check for updates for this application at the configured frequency and automatically download and apply any future updates, with no user interaction required.

    Okay now that we know where we are going, I’ll discuss how we got there.

    Deploying an Application

    We just effectively performed an XCopy deployment of a .Net application. We could have executed MSI as well.

    Here’s my application:


    It’s called AppLife Sketch, and it’s a WPF application that consists of an exe and a bunch of assemblies. A common scenario.


    So, in preparation for distributing this application with AppLife Update, we’ll need to answer a few questions.

    1. Where do I want to install the application on the client? When deciding, we can use any Windows environment variables. We’ll install Sketch for all users in the Program Files directory.

    2. Do I want the updates to be installed automatically, without any user interaction?
      I can choose to have AppLife Manager automatically detect updates and install them, or have the AppLife Manager prompt the user through the Windows System Tray to apply updates. I’m going to choose to have the updates automatically applied. If the application is running, the user will be prompted and offered a chance to defer the update until a later, more convenient time.
      There is a third option as well, which is to have the updates automatically applied during designated off-peak hours only. I’m not going to configure that option for now.
    3. What is the name of the application process? AppLife Manager uses this to determine whether the application is currently running, and to shut it down if needed.

    4. Who do I want to make the application available to?
      It can be anonymous, or limited to a specified list of clients. I’m going to create a list and allow only a specific Client Access Key access to the application and its updates. A Client Access Keyis a value that is entered on the client, as the server is registered in AppLife Manager.

    Anyone client using this Client Access Key will gain access to this application.

    That’s all I’m going to need to know. Now I can get started.

    Creating the Application on the Server

    The first thing I need to do is create a new application on my AppLife Server. You could also provision a new application on the AppLife Update cloud service. My server is at


    I’ll also create the Access List for this new application and assign a Client Access Key, so that it’ll be available when I set up the update build project.


    With an application available on AppLife Server, next I’ll create my AppLife Update project in AppLife Builder. To do so, I’ll first need to download the AppLife Update product, if not already done.


    Click the Create a new project link. This will create a new AppLife Update .aup project file. A New Project Wizard is launched and we’ll select an AppLife Manager Maintained Application.

    To login to the AppLife Server, provide the URL and your credentials.


    My applications that are not yet configured are listed.


    Once I select my application, I can configure the application for our desired behavior. Here is where I determine where the application will be installed, the process name and the primary executable.


    And finally, I select the list of Client Access Keys that will have access to the application.


    When I finish the wizard, the application is configured on the server and I’m now ready to create and publish update packages that will be distributed through the server.

    Creating the Update that Installs the Application

    As mentioned, we are going to effectively XCopy deploy the application. We’ll use three actions in the update.

    1. Add & Replace Files – This action will add the list of files that comprise the application to our designated Application Directory. Within the action editor, Application Directory is what we defined previously (%ProgramFiles%\AppLife\Sketch).
    2. Add a shortcut to the Common Start Menu. This shortcut will launch the application.
    3. Set the current version of the application for AppLife Manager. The default method of identifying the current version of our application on deployed clients is through the AppLife Manager configuration. When using this method, the Set Update Version update action will maintain the correct version stamp of the updates.

    That’s it. When we publish the update, we can target any previous version, as this update replaces the application in its entirety.


    To create the update, click the Create an Update button and walk through the publish wizard. Here, you’ll define what the version of this update is, what previous versions can successfully apply the update, and summary text desired.


    Then we log into the server and define the access mode.


    And that’s it. Our application is set to be deployed.


    With AppLife Server and AppLife Update, we can very easily deploy and maintain applications with no user interaction required. We can control which deployed clients get what applications and/or individual updates. We can do this without any source code integration or, or even opening a development environment. For more information on AppLife Server and AppLife Update, visit the online help system.

    Posted at January 5, 2018 | Categories : AppLife Manager, AppLife Server, AppLife Update |
  • Reviewing Update History with AppLife Server

    There are many advantages to hosting your update packages with AppLife Server over a standard http file server. One big advantage is the ability to drill into your deployed install base and investigate what is going on out there with your applications. Once logged in and navigated to your specific application, using the search box to filter down the client list provides a lot of information. Say you want to see which deployed clients have not updated to the most recent release. Just enter the previous version number in the search box and you’ll be looking at all of the clients that are still running your previous version.


    You can search for any of the values listed for your deployed clients. To review the update history of a specific computer, search for a computer name or known Client Access Key.

    Here’s my laptop (BRIANHLT2).


    The last time I ran this particular application was on 2/1/2016. And to see all of the update history for this installation, click on the information icon.


    And if we look into the last update from version to we have:


    If this had been a failed update, information about the reason for the failure, and most importantly, the location of the update execution log on the deployed client would be displayed.


    Access to deployed installation status can be very valuable in troubleshooting issues that arise as well as ensuring updates are being deployed as you expect them to be. Hosting with AppLife Server provides all of this information to you.

    Posted at February 17, 2017 | Categories : AppLife Server, AppLife Update |
  • Insert Raw Xml During an Update

    The Change Xml Node action can be used to add content to an Xml Node, and it can also insert additional, or raw Xml into a file.  To insert raw Xml, uncheck the option to Use Xml encoding in replacement text.


    Here’s an example of when this feature comes in handy.  The objective is to insert two new entries into the web.config assemblyBinding node.  We can replace the entire content of the target node as raw Xml.  After an update, we end up with:

    Non - Encoded Insert

    Here’s what is inserted if we do not uncheck the box:

    Encoded Insert

    Clearly not the desired result.

    Posted at January 12, 2016 | Categories : AppLife Update, Software Maintenance |
  • GO Statements in Run SQL Action

    What’s in a GO statement?  Quite a bit actually.  Contrary to popular belief, GO is not actually part of T-SQL.  It is a command recognized by the sqlcmd and osql utilities and the SQL Server Management Studio Code editor.  When we created the Run SQL Query update action, we included parsing on GO during the update build process, which allowed users to execute their migration scripts when including them as a .sql file.  This works nicely for pure SQL.  However, when SQL is inserted into the action editor, it is parsed real-time as the update is executing. In this context, the the SQL was passed directly into a SQLCommand object and executed.  GOs don’t fly there.  So why wouldn’t one just put their SQL into a .sql file and let the build process parse the GO statements?  Shared Property expansions.  If you want to use Shared Property information as part of your SQL input, things became difficult.  With AppLife Update 5.1, we’ve added GO parsing to the update engine and what was once difficult, is now quite easy.


    Posted at May 1, 2015 | Categories : AppLife Update, Software Maintenance |
  • Introducing AppLIfe Update 5.1

    AppLife Update 5.1 was released today. Some new features added includes:

    • Improved Run SQL Query Action
    • The new Run SQL Query action now supports the use of the GO statement in SQL added directly to the action editor.  GO has always been supported in linked query files, but not in directly entered SQL text.  This is significant as the only place Shared Properties are supported is within SQL entered directly in the action editor.

    • Pre/Post Build Script Update Version Variable Definition
    • Pre/Post build scripting now has access to the Update Version being built within the scripts.  This is especially useful when local paths include the version being built and scripting around those file paths must take place before or after creating a new update.

    • New Shared Property Action Options
    • There are two new options when creating a Shared Property through the Set Shared Property action.  Number (double) values can now be created. Also, the Update Publish Date/Time is available to be assigned to a Shared Property.

    • New Display Property option on the Execute MSI Action
    • The text displayed to the user during the execution of an MSI using the Execute MSI action is now configurable.

    • Added API Access to Update Summary Text
    • Update Summary text from any locale’ can be accessed through the Update Controller API.

    Posted at March 31, 2015 | Categories : AppLife Update |
  • Replicate Updates Locally

    In situations where there are many deployed systems located on the same local network combined with a need to minimize bandwidth utilized in retrieving application updates it is advantageous to provide a means to download update packages only once for everyone. With a new feature of AppLife Update 5.0, creating this ability is quite easy.

    After an Update Controller checks for and downloads available updates, you can now save the downloaded package(s) and Director.Xml file to a local folder by calling the Update Controllers SaveUpdatesToLocal method.

    As an example, let’s modify the C# Simple Quick Start project that ships with AppLife Update to first check a local folder for updates before checking the public location. Any updates downloaded from the public location will be copied locally for other local systems to find. To accomplish this, we’ll add a few Main form variables to hold the Public and Local update locations.

    1:  public partial class Form1 : Form {  
    2:   private string mPublicUpdatePath = @"http://www.kin…/SaveToLocalExample";  
    3:   private string mLocalUpdatePath = @"P:\Updates\SaveToLocalExample";  


    This Quick Start uses the UpdateDisplay control to manage the update process.  To integrate with that process, we will use the CheckForUpdateCompleted and the DownloadUpdateCompleted events of the Update Controller.

    Basically we are going to initially check the local update folder for updates.  If no updates are found locally, we’ll check the public update folder.  If we find any updates in the public location, we’ll save them locally with the new SaveUpdatesToLocal method.  So here goes.

    Modify the Update Controller’s default Update Location to be the local update path, and then attach to the two events.



    First, lets handle the CheckForUpdateCompleted event.  This event fires whenever the Update Controller completes an update check.  If the private location was checked, we’ll just switch to the public location and check again.

    1:  private void updateController1_CheckForUpdateCompleted  
    2:       (object sender, CheckForUpdateCompletedEventArgs e) {  
    3:       UpdateController c = sender as UpdateController;  
    4:       if(c.UpdateLocation == mLocalUpdatePath) {  
    5:            //we checked the local path. If we didnt find any  
    6:            //updates, lets check the public path  
    7:            c.UpdateLocation = mPublicUpdatePath;  
    8:            c.CheckForUpdateAsync();  
    9:       }  
    10:  }  

    And then finally, in the DownloadUpdateCompleted event, we’ll look to see if the update that was just downloaded came from the public location.  If so, we’ll save it to the local folder using the new method.

    1:  private void updateController1_DownloadUpdateCompleted  
    2:       (object sender, AsyncCompletedEventArgs e) {  
    3:       UpdateController c = sender as UpdateController;  
    4:       if(c.UpdateLocation == mPublicUpdatePath) {  
    5:            //downloaded an update from the public path. Save it locally  
    6:            c.SaveUpdatesToLocal(mLocalUpdatePath, false);  
    7:       }  
    8:  }  

    If multiple update packages were downloaded as a chain collection, all of the update packages will be saved by the SaveUpdatesToLocal method.

    Posted at March 1, 2015 | Categories : AppLife Update, Deployment, Software Maintenance |
  • Applying Cached Updates

    A new feature of AppLife Update 5.0 allows your applications to easily apply updates that have previously been downloaded by your applications. This is very useful when your application resides on field computers that come and go from your primary network.

    All that is required to do to use this feature is to set the Update Controller’s Disconnected NetworkEnableOfflineUpdates property to true. By default, this feature is not enabled. Once set, any updates that get downloaded are made available to the update controller until they are applied. They will be available even if network connectivity is lost.

    A common use-case for this feature is when applications are configured to check for and download any updates upon application startup and at certain intervals while operating, but defer the update process until the application is shutdown or restarted. In these situations, the deferred updating process might well take place when the deployed system has been moved away from the network. If the EnableOfflineUpdates property has been set, the update process can proceed whenever it is convenient for the user, regardless of whether or not a network connection is available.

    Posted at January 21, 2015 | Categories : AppLife Update |
  • Introducing AppLife Update 5.0

    AppLife Update 5.0 was published today and includes many new features.

    AppLife Update Server Support

    AppLife Server is the most secure and reliable platform to host AppLife Update packages.  With the release of AppLife Update 5.0, App

    Enable Cached Update Checking

    Previously downloaded but not yet installed updates are now cached locally and can be used to apply an update at a later time even if network connectivity is no longer available.

    New Update Actions

    Check File Exists

    Update Display Version

    Install .Net Framework 4.5

    Read File/Assembly Version

    Custom Update Window Improvements

    Support for including IUpdateUI implementation dependency assemblies into the update package.

    Save Downloaded Update and Director.Xml Locally

    API extensions allow for saving downloaded update packages and corresponding Director.Xml to a local folder.  This extension can be used to implement an updating scheme where multiple local installations can download an update package once and use it multiple times.

    Posted at February 26, 2014 | Categories : AppLife Update |
  • 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.

    Posted at September 28, 2012 | Categories : AppLife Update |
  • 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.

    Posted at September 18, 2012 | Categories : AppLife Update, Software Maintenance |