Simple Auto Update for WPF Apps, without the Updater Block

I am writing some smaller WPF apps, and I want them to automatically update themselves, something like Lutz Roeder's Reflector or Paint.NET does.   Scott Hanselman has commented on this previously, and he's right. Every app ought to be able to do this.

I looked into the Application Update Block, which was last updated I think in 2005, and is at version 2.0.  This is a thorough app block that seems to do "everything".  But it's a little too much for me.  It requires the Enterprise Library stuff, it all feels like too much work.  Too much configuration, too many options, too much flexibility. 

My apps are small, single EXEs, no installation, no config files, and so on.  This is a very very simple scenario.  The Updater Block is overkill.

I looked into using AppDomains and getting fancy that way, but I didn't like that approach either. Too complicated, too unnecessary.  The AppDomain is a nice structure if I want the process to continue living through the update lifecycle.  But I don't need the process to live forever.  I don't care about re-cycling the process.  So AppDomains seem like the wrong approach too.  

I also looked around for some biolerplate code produced by someone else, something I could re-use.  But I couldn't find anything accessible.  I think there are commercial third-party components that do this, but this was just for some really basic apps, I didn't want a commercial solution.  So, I built it myself.

A Simple Approach to Self Patching Apps

There are really two steps to the auto-update trick.   First is to find out the latest version of the app, Second is to get the latest version and replace the old version with your new version.  The first problem is simple, just an HTTP GET (in the REST tradition) on a text file containing the version number. The second problem is more challenging.

The EXE starts up, and it can do the HTTP GET to find out it needs to be updated.  But then what?  Of course, the app could go get the updated version of the app image, with the same kind of HTTP GET.  For a reasonably sized app (let's say up to 1mb EXE image size), this will be reasonably fast, well within the realm of acceptable performance.   BUT, while the EXE is running, the EXE Image on disk is locked.  It cannot be overwritten.   

What I settled on was this: have the executing application replicate itself.  The App starts up.  Let's say it runs in process 1.  checks for available updates.  If it finds an update, it replicates - copies its EXE image to another location, a temporary location.  The original  process then does a Process.Start() on that copy of the EXE, we now have process 2.   Then the original process (#1) exits!.   This unlocks the original EXE image on disk, so that it can be overwritten.   The process running from the temporary copy location, now downloads the latest, updated EXE image, and copies it to the original location.  The Updater clone process then does a Process.Start() on the original EXE location.  This creates process #3 Then the updater clone exits (process #2).  Now the process #3 starts up, checks for updates and finds none, since it is the running from the latest EXE image. The process #3 can also clean up any EXE "updater clone" images , but that is just good manners and not strictly necessary for correctness.

This should work with any WPF or WinForms app. 

Here's what the code looks like in your app (call something like this in the constructor of your WPF Window):

Essentially you are telling the user whether there is an update available or not. 

When it starts up, the sample app looks like this  :

If the user clicks the "Get the Update" button, then you do something very simple:

That's it!

When the user clicks the button, the window disappears, and then the app starts up again.  It all happens pretty fast for a small app.  For my sample app of around 28k, it happens in less than a second. 

Now, in general, people will want different user interaction models.  They don't want to ask the user if they want to check for updates, every time the app runs.   Typically, I want the "check for updates" to happen in an About Window.  But that's simple, too.  Keep the initialization the same, and just put the call to Updater.UpdateApp() in the code behind for the button in the About box.

I hoepe this is useful.

The source is attached here.  It is all C#.  This requires the .NET Framework v3.5, because I use lambda expressions in one of the routines.  If you are savvy you will quickly be able to swap that out for a named delegate that is supported in .NET 2.0/3.0.

Hmmm, what about Security? 

My first crack at this just used a text file holding the Version tuple (1.2.3.4), and if the version was different, the app would download itself and there ya go.  But the security of that approach was pretty loose.  I saw an older comment from some guy named Mike, who described an approach to signing an XML manifest file, and including an MD5 hash in that manifest.  So I adopted that approach.  I used this codeproject article to do setup the keypair and crypto.

Rather than just uploading a text file containing 1.2.3.4, I had to build a little tool to construct and sign the XML file.  But that is the only big change from the model.  The application does the same thing - the Updater works the same way.  I couldn't figure out how to attach that tool to this post, along with the source to the sample app, so the tool will wait for the next post.

This really has nothing to do with Interop, but it's a handy thing to have.  Now, go and be cool, and build self-patching, auto-updating applications.