There are many update actions available in AppLife Update to manipulate files on deployed systems during a software update. You’ll see in the list of update actions, that there are actions to replace files, and also actions that patch files and folders. When would you choose a patching action over a replacement action? What’s the difference anyways?

Replacing Files

Update actions that add & replace files will place the complete and intact file into the update package during the update build process, and then as the update package is executed on a deployed client, the intact file is extracted from the update package and replaces the existing previous version.

Patching Files

Actions that patch a file or folder do not place the entire file in an update. Instead, during the update build process a difference file is generated by comparing an earlier revision of a file with the current revision and this difference file is added to the update package. Difference files are often much smaller than a complete file, which results in a significantly smaller update package. As the update is executed on the deployed system, the difference file is combined with the earlier version to reproduce the current version file.

Advantages & Disadvantages

Replacing files makes an update far less dependent on the specific version of the application being updated on the deployed client. For many applications, using replacement file actions allows their update to successfully update any previous version. In this scenario, once a new version update is published, previous updates are no longer necessary and can be removed from the update server.

The advantage of patching files is that update packages can be significantly smaller in physical size.

The disadvantages of both types are converse to their advantages. Replacing files results in much larger update packages. The disadvantage of patching actions is very stringent versioning requirements.

So when would you choose one over the other? Here are a few factors that can contribute to this decision.

1. Are specific file versions reliably present?
If the specific version of a target file cannot be guaranteed based on the installed version number of the application, patching cannot be used. The difference file must be combined with the exact base file used to create it. If that exact file is not present on the deployed system, the new file cannot be created during the update process and the action will fail.  This situation can occur when end users might manipulate the files and assemblies in the application installation directory.

2. If the files to update are physically small, the number of clients to update is small, or network bandwidth is not a concern, consider using file replacement actions.
In general, file replacement actions are more robust due to the lack of specific file versioning requirements. In addition, because updates can target many previous versions, clients that do not regularly update their software as updates are published will apply fewer updates.

3. To minimize update package size, use patching actions
Applications with many deployed clients, or physically large files should consider using patching actions. A Patch Folder action can operate recursively on an entire folder structure, making it easy to patch the entire application with a single update action. When using patching actions, it is necessary to build your updates to target specific previous versions.

4. Consider combining both patching and replacing
For some applications, certain files can be safely patched while others cannot. Both file action types can be used in a single update.

Wrapping it up, with AppLife Update you have a choice to patch files or replace files during an update. Patching creates much smaller update packages, but requires strict adherence to versioning. Replacing files creates larger update packages but is far more forgiving and allows a single update to target multiple previous versions. So choose the right strategy or your application and start updating!

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.

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.

 <UsingTask AssemblyFile= "C:\Program Files\AppLife Update\Build Automation Utilities\MSBuild\Kjs.AppLife.Update.BuildUpdateTask.dll"

 	   TaskName= "Kjs.AppLife.Update.MSBuild.BuildUpdate" /> 

<Target Name= "AfterBuild"> 

 	<BuildUpdate 

 		Condition= " '$(Configuration)|$(Platform)’ == 'Release with Update|AnyCPU' "

 		ProjectFile= "..\Simple.aup "

 		UpdateVersionSource= "$(OutputPath)\$(AssemblyName).exe"

 		TestOnly= "false"

 		PublishLocations= "Update Location" /> 

 </Target>

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

That’s it!

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

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.

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.

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.

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.

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.

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.