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.

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.

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.

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.

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.

http://www.kineticjump.com/update/

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. 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.

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.