The AppLife Update Blog

  • Accessing Local Directories during an Application Update

    Most application files reside in the installation directory, referred to within AppLife Update as the Application Directory. The AppLife Update execution engine determines the Application Directory from the physical location of the executable that launches the update. When any of the file related update actions are added to an update action list, the default directory that is targeted is the Application Directory.


    This is most often the location where files need to be added or replaced during an application update. Accessing paths relative to the Application Directory can be accomplished using the subdirectories property.


    And navigating up the directory tree…


    In addition to the Application Directory, you can target any of the well-known named folder locations as well, such as the current user’s profile directories.


    Using an Explicit Path

    You’ll notice in the list of directories, there is an Explicit Path option. This option lets you specify the entire path to use for the file action. At first glance, this feature doesn’t look all that useful, but when combined with Shared Properties, it becomes a very nice feature.

    Expanding Shared Properties in Place

    Shared Properties can be used in many action properties. Most of the properties of built-in actions have the ability to expand a Shared Property in place. These properties are adorned with a blue icon indicating their support of this feature. A Shared Property is inserted using $$ delimiters, and during update execution, the value of the designated Shared Property is inserted in-place of the delimiter.


    So for file actions, we can use a Shared Property to target an explicit folder, which opens up lots of possibilities because Shared Property values can be passed in from the host application, set by other update actions that can read from a database, the registry, xml config files, or custom actions running your own code.


    An Example – Maintaining Office Templates

    Say your application installs templates for Microsoft Office and you need to maintain those templates during an application update. There is a default location for Office templates however this location is user configurable, so it could be different on every system. The default template location is located in the current user’s roaming application directory.


    If the user has specified a custom template location, we can find this path in the registry.

    HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\General - UserTemplates

    One caveat is that if the user has not specified a custom location, this registry key is not present. So in order to target the correct folder, we’ll need to read the user configured location from the registry, and then use that location with an Add & Replace files action. If the registry value is not present, we’ll also set the default value of this shared property to the correct default location by expanding another Shared Property.

    Action 1 – Add a Set Shared Property action and set a Shared Property to the current user’s local roaming AppData folder path. We’ll use this to set the default value in the next action.


    Action 2 – Add a Read Registry Value action to get the User Configured template directory from the registry and assign the value to a new Shared Property. If the value doesn’t exist, we’ll set the default value with the path identified in action 1.


    Action 3 – Add an Add & Replace Files action and use an explicit path to target the correct templates folder.


    Using Shared Properties and explicit paths, we can easily access and maintain files and assemblies in any local directory that our application uses.

    Posted at 12 July, 2012 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • Updating Software Operating on Erratic and Unreliable Networks


    Example Project Source Code

    When your software operates in an unreliable networking environment, it can be very challenging to automatically maintain your software installation. These environments are quite common. Police cruisers and ambulances use laptops to run software in the field, relying on cellular technology to distribute updates. Traveling salesmen use proprietary laptop business software and are constantly going in and out of network coverage. Medical staff use their mobile pc’s in large medical facilities, where dropping connections in elevators and dead Wi-Fi spots is common place. In scenarios like these, professionals are using software that must be maintained. In today’s professional environments, software maintenance is expected to “just happen”, without interrupting the work of the professionals using the software. Software publishers who create software that operate in environments like these all face the same challenge of maintaining their software without requiring support staff to take possession of the hardware. The AppLife Update Solution provides the answer for many software publishers whose applications operate in environments like this.

    With the AppLife Update solution, software publishers create and publish self-contained update packages that migrate an installation from one version to another. These update packages are retrieved by the client software when network connectivity is present. Once the update package is retrieved, network connectivity is no longer required and the update can be applied, performing the work necessary to maintain the deployed installation. As the update package is downloaded, the partial download is cached locally so that any interruption in network connectivity will not require restarting from the beginning.

    The flexibility of the AppLife Update solution provides the ability to change the behavior based on known circumstances. When it is known that the software being maintained is going to operate in an unreliable networking environment, it is possible to handle network connectivity errors differently than normal. Normally a network connectivity error would be unexpected and the user would be notified of the situation. Instead, the application can postpone the update retrieval operation for a short period of time and try again. And try again. And try again, until the update retrieval succeeds and can be applied.


    Example Implementation

    In the example project accompanying this post, the updating functionality is completely automated. The implemented updating process can be described as:

    When the application launches, a background update check is performed. If an update(s) is available, the update packages are retrieved in the background and without user interaction. If network connectivity is lost, the retrieval is postponed and continually retried in the background without user interaction until the update is successfully retrieved. Once retrieved the user is prompted to either apply the update now, or when the application is closed. If the user elects to apply the update, the update is applied and the application restarted. If the update is deferred until the application exits, the update is applied as the application exits and the application is not restarted.

    The example project contains an Updater class that controls the update check and retrieval process. Inspecting the Updater class, you’ll see that the class maintains an AppLife Update Controller and uses the API methods and events of the update controller to pause and retry as network errors occur. When an update package is successfully downloaded, an event is raised, alerting the primary application that an update is ready to be applied. The implementation code in the primary application is very simple. An Updater class is instantiated and the Update Controller properties are configured. Once configured, the GetUpdateCompleted and GetUpdateProgressChanged events are hooked before calling the GetUpdateAsync method. That’s it. Any updates will be retrieved as the network allows. When the completed event fires, the Updater status is checked and the user is prompted to apply the update now or when the application exits.

    Implementation Details

    The Updater class is the heart of the implementation. It has a very simple interface:


    The Updater class wraps an AppLife Update Controller and exposes a single method that implementing code will call to perform the entire update process.

    We want to take a look at the GetUpdateAsync method. This method calls the Update Controller’s CheckForUpdateAsync method and then returns. The update process continues in the CheckForUpdateAsyncCompleted event handler. If an update is present, the DownloadUpdateAsync method is called. When the download completes, the GetUpdateCompleted event is raised. When these asynchronous methods are called, any network errors will cause the completed event to fire, and the event argument’s Error property will indicate the cause of the error. Based on the error information, we can take appropriate action. In this example, we are considering any WebException or IOException to indicate a network error. Your implementation can improve on this, based on environment specifics. At any rate, when a network error is detected, the updater class goes into a wait mode and try’s the check/download again after a period of time. Eventually, the update download is completed, and the GetUpdateCompleted event is raised, triggering the client application to prompt the user.

    Of course, the user experience behavior is completely customizable with just basic coding. The AppLife Update Controller performs the heart of the technical challenges involved in this implementation, and the Update Engine is what lets you package up any work that is necessary to maintain and migrate your deployed installations. So I invite you to take a look at the example and evaluate it for suitability in your own environment. Feel free to contact our technical support team with any questions.

    Posted at 3 July, 2012 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • Easily Modify .Config Files During an Application Update

    The beauty of .Net configuration files (.config) is that they let you easily change the behavior of your application for individual installations. This allows for a great deal of flexibility, especially with service related settings. With this flexibility though, also comes a maintenance challenge. Unlike all of your other application files, configuration files usually can’t be simply replaced during a maintenance update. Doing so would lose any customizations made to support the specific application installation. As your application evolves, it is inevitable that your configuration files will require modification. With AppLife Update, you can easily maintain .Net configuration files without replacing them by modifying the existing files. I’ll cover three different methods that you can use, based on the type and scope of the config file modification that is necessary.

    • Modify the existing config file directly using Xml Update Actions
    • Migrate specific settings from an existing config file to a new config file using Shared Properties and Xml Update Actions
    • Utilize custom .Net code to manipulate the config file during an update

    Modify the Existing Config File

    Using Xml Update Actions is great for adding elements and updating attributes. As an example, let’s say that we use appSettings in our application and we need to add a new appSettings value in support of a new feature. We can use an Add Xml Element update action to insert a new appSettings value into the existing config file.

    This is what the v1 application configuration file might look like:


    But for v2, the configuration file might need to look like this:


    To migrate version 1 installations to version 2, in addition to replacing the application assemblies we must add a new entry to the appSettings collection. To do this, we’ll use an Add Element update action.


    When configuring Xml update actions, XPath expressions are used to reference the specific Xml elements that you are interested in reading and writing. To accomplish our goal, we will use an XPath expression to access the appSettings node, and then add a new element to that node. The config file is located in the Application Directory and is named Simple.exe.config.

    The XPath expression is /configuration/appSettings. The element that we are adding is:

    <add key=”key2” value=”value2” />

    The name of the element is add, and the new element has two attributes, key and value. Add a new Add Element update action to your update project and configure it as below.


    With this action in place, the new element will be added to the configuration file when the update is executed.

    Another scenario where Xml actions are great is when we need to update a specific attribute. Using a Change Node action, the value of an existing appSettings entry is easily accomplished. For instance, consider the situation where in v3 of our application, we needed the key2 value to be modified to value3. This can be accomplished in a very similar process. Instead of adding an Xml Element, we can use the Change Node update action to modify an existing value. To accomplish this, we need to know the XPath that references the specific value that needs to be changed. In this case, the XPath expression is /configuration/appSettings/add[@key=”key2”]/@value.


    Adding a Change Node action configured like this will modify the attribute value to “value3”.

    Migrate Existing Values to a new Config File

    In some circumstances where there are wholesale changes to a config file that would require extensive modifications to the existing file, it could require less effort to extract specific values that are unique to the installation and migrate them to a new config file. In this scenario we use Xml Actions to read specific information from the existing config file and store that information in Shared Properties. We can then replace the config file with an Add & Replace Files update action, and finally use Xml actions to write the information that we stored into the new config file.

    Revisiting the previous example, we’ll take this approach for the necessary modifications. We’ll read and store the value of the key1 appSetting, then replace the config file and modify that value in the newly replaced configuration file.

    Reading the existing value, we’ll add and configure a Read Xml Node Action. Using this action, we set the config file name and XPath just as before. We’ll also designate a Shared Property to store the attribute value. Shared Properties are essentially variables that are scoped across the context of the executing updates. They allow for information to be shared between update actions. The Read Xml Node action will assign the string value of the designated attribute to the designated Shared Property.


    With the value of the existing attribute stored, we can replace the application configuration file using an Add & Replace Files action.


    After this action executes, the application configuration file will be replaced with a new updated version. However, the value of the attribute we are interested in will also have been reset to its default, non-customized value. To complete the update process we need to use the value that we previously stored to change the new configuration file. A Change Xml Node update action will update the attribute value. When using string value Shared Properties, the value of the Shared Property can be expanded using $SharedProperty$ syntax.


    The Change Xml Node action restores the value originally set on the specific client and completes the update process.

    Utilize .Net Code to Modify an Existing Config File

    When using Xml Actions and Shared Properties, we read and write string values to the config file. In some circumstances, it can be beneficial to approach the Xml maintenance process within code, where the Xml can be manipulated in fragments. This too can be easily accomplished during an update using the Dynamic Code Action. A Dynamic Code action allows you to easily create a custom update action, which extends the UpdateAction class and overrides, at a minimum, the Execute and RollbackExecute methods.


    With a Dynamic Code action you can use C# or VB.Net code to manipulate the deployed client. Here we use the context parameter to access the information we need to accomplish our goal in code. You can access local directory information as well as the Shared Properties collection. With this information, we load an XmlDocument and manipulate the file within our custom code.



    During software maintenance updates, application configuration files that are uniquely modified for each installation cannot be simply replaced as changes are made to support new versions. These config files must be modified in-place during the maintenance process. Using AppLife Update, application configuration files can be easily maintained throughout the life of the application and we present three different approaches to accomplishing the goal.

    Posted at 31 May, 2012 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • Updating a Windows Service

    For applications that deploy a Windows Service, updating the installed service can present a maintenance challenge. This is a scenario where integrating AppLife Update makes a difficult task extremely easy to accomplish. Using AppLife Update actions, a Windows Service can be updated in three easy steps.

    1. Stop the Service using a Stop Service update action.
    2. Replace the Service assemblies using one of the available file replacement actions.
    3. Restart the Service using a Start Service update action.

    Tada! Big maintenance challenge accomplished.

    An Example

    The release of AppLife Update 4.5 included a few very small changes to our AppLife Update Windows Service. Specifically, in previous versions, if the Windows Application Event Log was full and not configured to replace old events, our service would not apply an update. This issue affects a very small number of systems as since Windows Vista, the default logging behavior is to replace old log events when the event log is full, and the event log has to actually be full to cause an issue. For customers who use our AppLife Update Windows Service, if you choose, you can update the AppLife Update Windows Service on your deployed clients during your next application update. This is optional because if the logging issue isn’t a concern, you can leave the previous version alone. Any past version of the elevation service will operate properly with the latest AppLife Update controller. If you do so choose, here is how you can update the AppLife Update Windows Service (or any other Windows Service for that matter).

    Stop the Service

    To stop the service, we need to know the service name. If you don’t already know the name of the service you are updating, it can be found in the Services manager.


    Open your application update project file (.aup). Add a Stop Service action to your update. Set the Service to Stop property to the name of your service. In this case, the service name is KjsUpdateService2.


    Replace the Service Assemblies

    We use an Add & Replace files on restart action to update the assemblies. The AppLife Update Windows service is initially deployed using an MSI merge module, and is always installed to the Common Files Folder\AppLifeUpdateService2 folder. To update the service, we’ll select the Common Program Files (x86) client folder and set the appropriate sub-directory, and then add the two assemblies that constitute the service. Choosing the x86 variant of the Common Program Files folder will ensure we target the x86 common files folder on x64 operating systems. Using the non x86 Common Program Files directory targets the x64 folder on 64-bit operating systems. On x86 operating systems, there is only one common program files directory, and either variant will target the correct folder.


    Note: When updating most Windows Services, even when a service updates itself, the service assemblies can be replaced immediately, without deferring to a restart. The AppLife Update service core assembly houses a class used to marshal information between the User Interface process and the service started worker process. For this reason, even though the service is successfully stopped, a lock is still being maintained on the core service assembly while the update is executed. Because this lock is not released until the update completes, the file replacement is deferred until restart. We do not need to force an operating system restart, as the previous update service can be restarted and function properly until the system is restarted. If a restart were necessary, we could include a Restart Operating System action to accomplish this.

    The service assemblies ship with AppLife Update already embedded into the AppLifeUpdateService.msm merge module. After an installation, the assemblies will be in the common program files folder and can be extracted from there. After this action executes, the Windows Service will be updated. Now we just need to restart the service.

    Restarting the Service

    The service is restarted by adding a Start Service update action. The action is configured by defining the name of the service to restart. In this case it is again, KjsUpdatService2.


    That’s it! Windows Service update completed.

    But My Service is My Application?

    This example assumes an existing update process exists and can be utilized to update the Windows Service. This is usually an installed application that utilizes the Windows Service, and can take responsibility for updating it. A stand-alone Windows Service can become “Self Updating” just as easily by integrating an update process using an AppLife Update controller. There is one point to make in this scenario. When applying an update, you want to use the option to instruct the update controller not to shut down the host application (the service). The Stop Service update action performs a proper service shutdown through the use of the Windows Service Control Manager, and is the recommended method to use when stopping a service for an update.

    Posted at 9 May, 2012 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • Terminal Services Application Updating

    The AppLife Update solution is a perfect fit for maintaining applications that operate in multi-user terminal services environments. In a terminal services installation, there are likely many users simultaneously running your application. Application maintenance solutions must account for the fact that there can be multiple instances of an application running at one time as any running instance will maintain a lock on files and assemblies that must be replaced during an update process. The AppLife Update Solution ensures that all running instances of an application are shutdown prior to starting an update, and this is accomplished through a built-in Inter-process communications (IPC) feature. The IPC employed within AppLife Update communicates across all users and will shut down all instances of an application running in a terminal services environment, making the solution a perfect fit for maintaining terminal services hosted applications.

    Out of the box, AppLife Update will shut down all instances of an application and allow you to update a terminal services application. There is however some customizations that can be applied to an application that is known to be targeting terminal services that will improve the users application updating experience.

    Terminal Services Application Updating with AppLife Update

    User Experience Customizations

    The AppLife Update API provides an opportunity for the integrating developer to interact with the IPC process and update initiation (starting) procedure. We can use this opportunity to improve the user experience. For the instance that initiated the update, we’ll display an indeterminate progress dialog as all instances are being shut down, and for the non-initiating instances, we’ll display an informative dialog for a short period of time indicating that the application is about to be closed for maintenance. Further enhancements could allow terminal services users to cancel the update process, or perform additional work before the shutdown.

    Code Snippet
    1. private void checkForUpdatesToolStripMenuItem_Click_1(object sender,
    2.             EventArgs e) {
    3.         if(updateController1.ShowCheckForUpdateDialog(this,
    4.             ErrorDisplayLevel.ShowExceptionMessage) == DialogResult.OK) {
    5.             if(updateController1.ShowDownloadUpdateDialog(this,
    6.                 ErrorDisplayLevel.ShowExceptionMessage) == DialogResult.OK) {
    7.                 //Launch the update from another thread
    8.                 //To better accomodate terminal services
    9.                 //installations, the UI will remain
    10.                 //responsive as all of the other
    11.                 //instances of the application are closed.
    13.                 BackgroundWorker worker = new BackgroundWorker();
    14.                 worker.DoWork += new DoWorkEventHandler(worker_DoWork);
    15.                 worker.RunWorkerAsync(updateController1);
    16.                 ApplicationUpdateInitiatedDialog dlg =
    17.                 new ApplicationUpdateInitiatedDialog(true);
    18.                 dlg.ShowDialog(this);
    19.             }
    20.         }
    21.     }
    23.     private void worker_DoWork(object sender, DoWorkEventArgs e) {
    24.         //Since the ApplyUpdate method call is a
    25.         //blocking call, and we want the UI to remain
    26.         //response as the user waits for all instances
    27.         //to close, we'll initiate the update on a
    28.         //background thread.
    30.         UpdateController controller = e.Argument as UpdateController;
    31.         if(controller != null) {
    32.             controller.ApplyUpdate(ApplyUpdateOptions.AutoClose);
    33.         }
    34.     }
    36.     private void updateController1_UpdateStarting(object sender,
    37.             UpdateStartingEventArgs e) {
    38.         //An update has been an initated and this
    39.         //application will shutdown. This dialog will
    40.         //inform any other users that the application
    41.         //is about to shutdown on them. Showing this
    42.         //dialog is import for Terminal Services
    43.         //installations. Note: It is possible to
    44.         //allow other users to cancel the ongoing
    45.         //update process
    47.         //This dialog is shown for 5 seconds
    48.         //before it is closed automatically
    49.         if(!e.IsInitiatingController) {
    50.             ApplicationUpdateInitiatedDialog dlg =
    51.         new ApplicationUpdateInitiatedDialog(false);
    52.             dlg.ShowDialog(this);
    53.         }
    54.     }
    55. }

    Prevent Users from Restarting During the Update

    During the actual update, the application files must be unlocked, and remain unlocked throughout the process. If a terminal services users attempts to start the application using their application shortcuts, the application assemblies could become locked and prevent the update form succeeding. To prevent this, we’ll make the first action taken during the update be to rename/remove the launching executable. If the launching executable is to be replaced during the update process, we’ll perform this action as the last step of the update. By taking this action, terminal services users will not be able to launch the application during the update process from existing shortcuts.


    Download Terminal Services Example Project

    Posted at 21 March, 2012 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • No IT Needed

    When deploying custom software applications at the enterprise level it is almost always necessary to coordinate the release of maintenance updates with each customer’s IT department. This is sometimes required for QA and software validation, but most often it’s because the IT department holds the responsibility of pushing software updates out to the individual PCs.

    No IT Needed

    For you, the software vendor, you need maintenance patches to be installed quickly, sometimes very quickly, to ensure optimal user experience. For them, the IT dept, your software maintenance patch is just another of many tasks in the work queue. It won’t help to plead with them how important your release is. They support all departments, and every department thinks their needs are greater than the other guys, so they’ve heard it all before. This leaves you, the software vendor, potentially way down on the IT task queue. Fortunately for you, AppLife Update provides the tools to keep your deployed applications maintained without relying on the IT guy.

    What are those tools, you ask? Why it’s the AppLife Update solution, consisting of:

    • Update Controller
      This .Net control integrates into your application to manage discovery, download, and initiation of your maintenance updates.
    • Update Permissions Elevation Windows Service
      This Windows Service deploys with your application and securely applies your updates under the privileges of the local system account. Using the service your application, running under a limited rights user, can still maintain your installation without administrative support.
      **Initial deployment requires administrative privileges.
    • Update Engine
      The update engine is downloaded by the Update Controller and performs the update on the deployed client. The update engine can execute the Windows Installer packages that you are already creating to update your software. In addition, it can do so much more. There are many built-in update actions to help you maintain your deployed software, and you can even write your own update actions in C# or Vb.Net

    With these tools, and a day’s time, you can cast away those IT guy ties and take control of your application maintenance requirements, saving you and your customer time and money.

    Posted at 6 September, 2011 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • Application Updates and Mayhem

    Have you seen the Allstate mayhem commercials? They are pretty good. If you haven’t seen them, take a few seconds and watch the video below. At this point, you may be asking yourself what does that have to do with software. But then again if you’ve been around awhile, you may not be… These spots have a lot in common with software because in software, mayhem is everywhere.

    As a software developer, if you are not finding bugs, you’re fixing them. Mayhem. As a user, unexpected behaviors often occur as you go about using the software you use. Mayhem. And as an administrator, you spend a lot of time working around unexpected issues. Mayhem.

    And so it is with maintaining deployed applications, or automatic application updating. In a perfect world, an application update would never fail. Most don’t. And most houses don’t catch fire either, yet we buy insurance just in case. Around here, we put a lot of effort into ensuring that when a software update is applied, one of two outcomes will result. A successful update, or a complete rollback. We prefer the former, but plan for the later. And for most actions rolling back, and preparing for the rollback that hopefully will never occur, requires more development work than the execution of the action. Let’s look at files. Protection from mayhem is almost all of the work involved in file actions. The first thing we do is verify that our update process has permissions to replace the file. If we don’t, there is no sense in proceeding. We can stop before doing anything, preventing mayhem. Then we back up the file, including the assigned permissions, just in case mayhem happens later on, we can restore the original file. Such is the case with all of the built-in updating actions. With the exception of the Install .Net 4.0 Framework action, they either complete their work or rollback completely. For that action, mayhem is better avoided by leaving the framework successfully installed than to remove it during a rollback.

    Our Adjuster

    When mayhem happens, insurance companies like Allstate will send out an adjuster to determine the cause and extent of the damage. Our adjuster equivalent is the update action log files. When mayhem occurs, there are few things worse than having to tell your boss, “I don’t know why that happened”, because that means you also don’t know the answer to the inevitable next question. “How are we going to prevent it from happening again?” Update action logs tells the story of what happened (or didn’t happen) during an update, and with an update log you’ll know what happened and be able to determine how to prevent it from happening again.

    Software Update Log Viewer

    If your house burns down, we can’t help much. Hopefully you have Allstate for that. But for protecting your software updates from mayhem, look to AppLife Update. You’ll be in good hands.

    Posted at 8 November, 2010 | By :Brian Haas | Categories : Application Deployment | AppLife Update |
  • AppLife Update and .Net Deployment Strategies

    To deploy .Net applications, there are two primary activities that must be accomplished.  The application must be initially deployed (installation), and a deployed application must be maintained (update).  The two Microsoft technologies offered to accomplish these goals are the Windows Installer and ClickOnce.  The Windows Installer is a very powerful technology designed specifically to deploy software onto the Windows platform.  For many developers though, the Windows Installer can be very challenging to utilize. In fact, there are many third party vendors competing with each other to simplify the developer's interactions with the Windows Installer, each providing their own Windows Installer abstraction layer.  While the Windows Installer is flexible and can accomplish most any installation goal, it lacks easy maintenance features (updating), comes with heavy technical resource requirements and expects a lot from the end user, most notably administrative privileges.

    The challenges of application deployment strategies utilizing the Windows Installer, and the emergence of the web application combined to influence the creation of ClickOnce.  With ClickOnce, Microsoft attempted to bring the deployment simplicity of a web application to WinForms and WPF applications. And to a large degree, they succeeded.  For many applications ClickOnce does provide the best deployment strategy available.  But it's not for all applications, and because of the huge void in deployment capabilities between ClickOnce and the Windows Installer, many teams find themselves pushing the envelope of one or both technologies in order to accomplish their goals. For applications in that void, AppLife Update can add a tremendous amount of value to a deployment strategy.

    AppLife Update is generally used in conjunction with a Windows Installer, though its flexibility does provide for the ability to initially deploy applications without using an MSI.  Many of our customers adopt AppLife Update after first trying ClickOnce. Here are the primary reasons given for moving away from ClickOnce:

    1. Difficulty in moving applications. For developers who can publish directly the final deployment location, ClickOnce is very easy to use. But for teams who need to build at one location, and publish at another, ClickOnce is harder to manage. Development teams with QA and testing requirements also struggle with the same challenges in moving applications through their release process.
    2. Desire to install per machine. With ClickOnce, applications are installed per user.  For organizations that utilize roaming profiles, this means that applications are often installed many times on the same machine.
    3. Need for side-by-side installs.  With ClickOnce, installing different versions of an application on the same machine is challenging.
    4. Extensive installation requirements.  While it is possible to install ClickOnce application prerequisites using an MSI, the ease-of-use that ClickOnce offers is compromised, and these applications often push other limits of ClickOnce, such as security requirements.
    5. Network Environment.  Development teams whose applications target public audiences over the internet face browser incompatibility issues, plug-in requirements, proxy server challenges, the need for publicly recognized code signing certificate authorities, and security sandboxing issues.  What's worse is that initial ClickOnce testing usually passes with flying colors, but as the application use proliferates, costly support issues arise as users run into these problems.

    When development teams incorporate AppLife Update into their application deployment strategy, they get:

    • Flexible API / Extensibility.
      AppLife Update is not a black box. The API is extensive and allows for application-specific manipulation of the update process, from start to finish.
    • Versatile Hosting
      Updates can be hosted on any server (file, ftp, web) and freely moved around to support varying deployment and testing strategies.
    • Do anything during an update
      Any updating activity can be performed during an update. ClickOnce replace files, but AppLife Update includes actions to perform registry work, config file manipulation, register COM, Start/Stop Services, execute MSI major, minor upgrades, patches, etc. There is even a dynamic code action where defined .Net code is compiled during an update build and executed during an update.
    • Customized Look and Feel
      The entire look and feel of the update process is customizable. Use the built-in updating interface, customize it, or completely replace it.
    • Permissions Elevation
      Applications installed into Program Files cannot be updated by limited users. For applications that target controlled desktops, this is a huge maintenance hurdle. By utilizing AppLife Update's Windows Service to securely elevate permissions during the update, the application can update itself, even when launched by a limited user.

    AppLife Update provides the functionality to quickly and easily integrate application maintenance features into a .Net application, bridging the application deployment gap between Windows Installer deployed applications, and ClickOnce maintained applications. 

    For more information visit the AppLife Update product page, forums, Solution Lab, send us an email, or give us a call. (612) 486-9653.

    Posted at 9 April, 2010 | By :Brian Haas | Categories : Application Deployment | AppLife Update | ClickOnce |
  • .Net Application Updating in 60 Seconds

    The video below demonstrates how to update enable a .Net application in 60 seconds using AppLife Update.  And once enabled, maintaining deployed .Net applications is very easy.  In the video, you see an update created that replaces files and reads a registry key. The update then places the value from that registry key into the app.config file (an appSettings value). And for versatility, an MSI is installed and the registry key previously read in an earlier action is shown to the update user through a progress notification event initiated from C# code!

    This update video demonstrates a few of the common activities that are needed to update and maintain deployed .Net software. It only scratches the surface of what can be done with AppLife Update.

    If you are responsible for developing and maintaining a .Net application, you need to check out AppLife Update. Maintaining deployed release applications, as well as beta and QA installations have never been this easy.

    Posted at 3 March, 2010 | By :Brian Haas | Categories : Application Deployment | AppLife Update | Software Updating |
  • I Think I'll Roll My Own Application Updater

    Auto-updating deployed software is easy right?  I mean come on, how hard can it be to download a file from the internet and replace the old with the new. Why wouldn't I roll my own? I'd knock this out in a day or two.  All I'd need to do is...

    Replace some files

    I'll need to download the new files and replace the old ones.  Well... since my application is running and the files I need to replace are locked I'll need to do something with that.  Let's see, I'll just shadow load the exe.  When the application starts, I'll just copy it to another location and run it from there.  That way when my updater wants to replace it with the new one, it'll work.  I might have problems when I want to add another assembly to my application. rollyourown I guess I'll have to copy all the assemblies when my app starts.  That could get messy, but it's quick and easy.  Moving on...

    I'll need to know when an update is available.  OK, I can just retrieve a little file that will tell me what the current update is.  If the current update is newer than what is on the client, I'll download it and replace the client file with the updated file.  What?  Hmmm.... your right.  This will have to be changed if I ever want to update just part of the install, but I'll sort that out later when I have more time and I actually need to do it.  On to downloading...

    Downloading an update

    Downloading should be easy. The .Net framework gives me the WebClient class, which will make it as easy as pie.  I'll probably want to give my users some feedback and let them cancel.  My updates won't be very big so I don't think I'll need to worry about resuming from a previously failed update.  Everyone has fast internet connections now anyways. What's that?  Proxy servers could be a problem?  Well that'll take some time to sort out, so I'll just auto-detect, and if that fails then those users will just have to download the installer again and update the old fashioned way.  You think I should worry about getting hacked?  Not likely.  After all, we're pretty small and don't have that many users.  If they did though, I better do something to prevent that. That'll take some time to sort out, so I'll worry about it when we get big. Maybe crypto-signing or something... later.  Let's move on to actually updating the client...

    Updating the client system

    This will be super easy.  I'll just launch a little exe that will download the new files and replace the old ones.  What? Permissions might be a problem?  Never mind all that.  My users are all administrators on their machines anyway. What? Vista and Windows 7 doesn't even let administrators replace files everywhere?  Well then my users will just have to install the application somewhere where they do have permissions to replace files, or get someone who does have permissions to update their software.  We'll make a better solution later when we have more time to sort it out...  We can always update the updater later.  What?  I know the updater is running!  I'll just have to shadow launch the updater too so that I can replace it during an update.

    And when the updater fails

    All I am doing is replacing a file or two.  Why would the updater fail?  The user can just tell me which files are replaced and which ones aren't.  Later... when we have more time we can back up the files before we try to replace them or maybe even totally change the way we update the files.  Someday maybe we'll even add some logging so that we can figure out what happened when things go wrong.

    Publishing updates

    We'll just copy the new files to our web server whenever we build a new version so that the updater can download them. That's easy enough.  Yeah your right. Maybe we should compress them or something.

    You know... this sounds like a lot more work than I thought.  It might take me weeks, not days to get this done.  I wonder if there is something I can buy that will do all this?  That would save me a lot of time.

    Posted at 25 February, 2010 | By :Brian Haas | Categories : Application Deployment | Software Updating |
  • Silverlight, RIA's and Application Deployment

    The lines distinguishing a web application from a desktop application have certainly been blurred with the adoption of application platforms such as Microsoft Silverlight and Adobe AIR. 


    Rich Internet Application, or RIA's, are what these applications are called.  They run in a browser, and most applications built on these platforms usually communicate with a backend server.  That sounds like an internet application.  But peel back a layer and you'll see that RIA's have much more in common with their desktop application brethren than your traditional server-hosted internet application.  These apps run in a browser, this is true, but they run completely on the client system.  Unlike a traditional web app, and much like a desktop app, once started, neither the server or the browser is really necessary. It's so not necessary, that upcoming releases the major RIA platforms plan to include a no-browser mode, so that these apps can run outside of a browser.  Right now, as I type, there are .Net development leads out there pondering whether they should build their next app as a Silverlight application or as a smart client app (WinForms or WPF) deployed through ClickOnce.  Cross-platform capabilities notwithstanding, the case for ClickOnce and WPF over Silverlight is so strong, it's difficult to understand why there is even an argument. Understanding comes in a word...

    Deployment.  It's like the four letter word (that's not a four letter word) of software development. Nobody wants to even think about having to actually deploy software.  The mere thought invokes headaches. Deployment is so much at the root of these decisions that we should be calling these applications Browser Deployed Applications, or BDA's.  A Browser Deployed Application is an application that can be downloaded and launched using any standards compliant browser and runs on multiple computing platforms.  More accurate I would say.

    The most interesting aspect of this is that over the same period of time that RIA's have come on the stage, deployment of thick desktop based applications has become so much easier than it once was, and hardware virtualization promises that soon we'll see seamless cross-platform capabilities though virtual functionality.  Surely, for many applications and target environments, the pain of limited development capabilities that come with RIA's would be much more burdensome and costly than the deployment challenge of today's .Net thick client applications.

    The future may indeed be computers with nothing but a browser installed. But that day is not today. Today, users still expect more than that from their computers and their applications.  Don't be afraid of software deployment. You just might spend less and get more by stepping out of the browser for your next application.

    Posted at 12 January, 2010 | By :Brian Haas | Categories : Application Deployment | ClickOnce | Silverlight |