AppLife Update

Build and Publish Software Updates from Visual Studio

So you’ve got AppLife Update integrated into your application. That was easy enough. You’ve got your AppLife Update project set up to build and publish updates from Make Update as you release software versions. To make the process of building your updates even easier, I’ll show you how to integrate update building and publishing directly into your Visual Studio project build process.

AppLife Update ships with an MSBuild task that we can use within a Visual Studio project file to build and publish updates as part of the Visual Studio build process. Using this, we’ll add a new Release with Update build configuration to a Visual Studio project. When this build configuration is chosen, an application update will be built and published as the Visual Studio project builds.

Start by extracting the Simple C# Quick Start project. This will give us a common project to work from.

Step 1 – Create a new build configuration.clip_image002

From the Visual Studio build menu, select the Configuration Manager.

Create a new build configuration and call it Release with Update. Select to copy settings from the existing Release configuration. We’ll modify the project to build and publish an update when this configuration is built.

Step 2 – Modify the Visual Studio Project File

From the Visual Studio project menu, select to Unload Project. With the project unloaded, you can edit it within Visual Studio by selecting the Simple project node from the Solution Explorer and from the context menu, select to Edit Simple.csproj. With the Visual Studio project file open in the editor, scroll to the bottom and you will see two commented out Target elements. Uncomment the AfterBuild target and add a UsingTask element that references the assembly that houses the BuildUpdate MSBuild task. This assembly is located in the AppLife Update install directory.

Inside the AfterBuild target, add a BuildUpdate task. Set the Condition attribute to execute only when the newly created build configuration is used. Details on the attributes of this task are available in the MSBuildTask ReadMe.rtf file located in the same folder.

 

Step 3 – Modify the aup project file to use the Release with Update output folder

The Add & Replace files action should look at the Release folder for its files. Add a path relative to the aup project file.

Simple\bin\Release\Simple.exe

image

That’s it!

Now, whenever you want to publish an update, you can select the Release with Update build configuration and build the project.

clip_image002[10]

Visual Studio Build Output

Parting Thoughts

Build a test update out of Visual Studio, or build to a test update location. Both options are just as easy. This prevents an inadvertent build from being available to end users, and provides a built in updating testing mechanism.

To build a test update, set the TestOnly attribute to true. For clients to see test updates, they must have a specific application setting in their app.config file.

To publish to a specific test update location, you can name the publish location in Make Update project settings, then change the PublishLocations attribute value to match this update location.

To be Automatic, or be Automated – There is a difference

A developer doesn’t have to look very hard to find an application that employs automatic updating.  In fact, there’s a good chance that an icon down in the system tray right now is informing you of an update’s availability. Some applications tell you ahead of time that updates are available, and some tell you after the fact that an update has been applied. Some are painstakingly obnoxious to the user, and some completely transparent. For most desktop applications, employing a system of automatic updating makes perfect sense.  But for many applications, especially applications consisting of services, server components and databases, automatic updating isn’t very desirable.  But almost always, an automated update process does make sense, and should be employed.Automate Software Updating

If your application is deployed to more than one location and development is ongoing, then the application should include an automated means to find updates and apply them.  Not always automatic, but always automated. There is a difference. An automated update process won’t just happen on its own, and it often doesn’t even inform the user when an update is available.  It’s there to provide a simple, consistent, single step process to update the installed software. Customers will thank you, and it cuts your support costs. 

If your responsible for back office software, you’ve no doubt had the unpleasant experienced of reviewing a software update procedure.  Software you installed a year ago, and haven’t thought of since.  You first have to re-familiarize yourself with software terminology and configuration before you can even make sense of the upgrade procedure. Time consuming.

And if your a developer, you’ve no doubt written an upgrade procedure, supported customers as they perform the upgrade, then tweaked the procedure for better understanding.  Time consuming.

AppLife Update provides the means to automate your application maintenance plan, and could make a significant impact on support costs, especially if your application upgrades involve a multi-step manual upgrade process. Even if your application is complicated, don’t assume that implementing an automated update process would be cost prohibitive.  If you were to start from scratch, it probably would be, but with the built-in actions in AppLife Update, along with the Dynamic Code Action providing the means to write and package up application-specific upgrading functionality, you’ll be automated in no time.

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.

Pros and Cons of File Patching, Update Chaining, vs Broader Multi-Version Application Updates

Say you have a .Net application.  From a deployment perspective, your application is a relatively normal application.  A primary executable, probably Windows Forms or WPF based, a class library or two, and a few third party controls.  The application has reached a shipping point and now it’s time to distribute it to more than a few workstations.  You’ve chosen to distribute your application using the Windows Installer.  You’re now faced with determining the strategy for maintaining the workstations that have installed your application.  Whatever strategy you choose to pursue, you will be confronted with this question:

When I update my application, do I replace all of my assemblies, making updating simple, or do I replace only what I just changed, making updates smaller, but more complicated?

This question is going to arise whether you create Windows Installer upgrades and patches, use a third party updating solution, or even consider rolling your own updater.  Regardless of the tool you use, at some point you will find yourself pondering the topic.  The physically small update is the apparent no-brainer.  The uninitiated may say, “of course we want our updates small.  Nobody wants to wait on updates, and we don’t want to waste bandwidth.  Net neutrality isn’t here yet!”   This is all true, and can be a compelling argument. So you march forward on the task… until the details emerge.  To keep updates small, versioning rears its ugly head.  An incremental update can only target specific previous versions.  For manually distributed software updates, as is often the case with Windows Installer deployments, knowing what version you have, and which patch, or patches, you need to apply becomes as big a deterrent to end-user updating as a larger update.

After considering the challenges of implementation, the simplicity of larger, but version agnostic updates will cause you to reconsider your seemingly obvious initial plan. This is a big reason why so many organizations start out attempting to distribute patches and incremental upgrades, but then revert to the far more common version agnostic approach of uninstall/re-install. (There are plenty of technical challenges involved in actually producing working Windows Installer upgrades and patches, which also plays a role here as well).

So which path do you choose?  Consider the following.

  • Frequency of updates

    If you are creating updates frequently, you want the update process creation to be as automated as possible. Decreasing the manual involvement increases efficiency as well as lowers the opportunity for mistakes. If you have the infrastructure to automate the creation of small, incremental updates then you should do so. If not, your update process will be simpler and less prone to error if you build larger, version agnostic updates. Even if you are doing this frequently.

  • Frequency of application use

    For applications that are launched and updated infrequently, accumulating incremental updates can create an undesirable user experience. Try to avoid forcing your users to regularly discover and apply multiple updates, one right after another. You should build larger updates that apply to more versions, or ensure your update process can apply multiple individual updates in a single update session.

  • Physical size of the application files

    Physically large application assemblies make for large updates. File patching can significantly reduce this size of an update, but requires strict control of which previous versions can apply the update.

  • Number of deployed clients

    For applications with many thousands of deployed clients, the network burden of larger updates is much more significant than applications with tens or hundreds of deployed clients. As your installed user base grows, minimizing the physical size of each update becomes far more important in order to manage your server bandwidth utilization without resorting to throttled update deployment.

  • Network Environment

    The network speed between the update server and deployed clients can dictate your decisions, especially when slow links are known to exist. When your application lives within slow networks, smaller updates are more desirable.

  • Background Download to Reduce the Burden

    Downloading updates in the background and informing the user when an update is ready to apply removes much of the burden the user experiences with larger updates.  It doesn’t remove the burden from the network though.

  • Infrequent Exceptions to the Norm

    Targeting multiple versions, and making exceptions when you need to update infrequently modified files, such as third-party tools and help documentation keeps the initial update implementation effort low, ongoing update creation simple, and minimizes the burden that updating places on the end-user.

    A commonly pursued solution to this updating dilemma

    is not to consider application updating as an in incremental progression, but rather a “synchronization” process.  A process where deployed workstation application files are kept in-sync with a master version located on a server.  This approach works well if the updating process only updates files. It doesn’t work so well when application maintenance also requires performing other updating activities, such as registry and data store maintenance.  Security and licensing concerns also make the “sync” approach more challenging and less desirable than version migration approaches.

    Our updating solution, AppLife Update, is an incremental updating solution.  Each update is self-contained, and includes all of the updating logic and new files/assemblies needed to migrate a deployed application from a previous version to a new version.  When an update is created, you get to choose which previous versions can successfully apply the new update.  You can target all previous versions, a list of discrete versions, or all greater than a previous version.  How you’ve defined the update obviously determines which previous versions you can target.  When defining an update, you have a lot of latitude in your decisions.  You can package and deploy Windows Installer databases, you can replace whole files, you can individually patch existing files, you can use update actions that automate the determination of which files need to be updated.  With an update system like AppLife Update, there is little difference in the effort needed to create updates that target all previous versions, or just the most recent version, however the bandwidth and user experience factors still need to be considered.

    The flexibility is there to create the application updating strategy that best fits your application and your organization.  If the size of the update package necessary to replace all of the assemblies built in a standard upgrade of your application is acceptable, your update process will be far simpler to create and maintain if you target all previous versions with each update.  If the factors involved with your application dictate smaller updates, you can easily extend your updating process to seamlessly discover and download multiple updates, as well as display to the user a unified updating experience.