Writing my own Auto Updater

Question

When writing my own auto updater, is there a general framework that I should be following?

A while ago I was reading up on how one should create a 'boot strapper' that will load first before the main application (since a running appilation can't be updated due to file locks etc.)

So any tips/best practices for this?

Answer 1

You'll probably have to write your own. As FOR mentioned, the basic idea is to put the latest version of your program (I'm assuming an EXE) on the server, and then have your application check with the server when it starts, and download the EXE from the server if it's a newer version.

I've usually implemented this as a web service that the application calls at startup. A couple of warnings about this approach:

1. The web service method needs to get the version number of the EXE on the server and compare it to the version number of the caller. If you use the Assembly class to read the version number of the server EXE, this will lock the file for as long as the web service instance is running (at least 20 minutes). As a result, you may sometimes have trouble replacing the EXE on the server with a newer version. Use the AssemblyName class instead - this allows you to read the assembly info without loading the assembly (and locking it).

2. The caller application can't replace its own file with the new version - you can't delete or update a running application file. What it can do, however, is to rename its own file while running. So the trick on an auto-update is for the application to rename itself (e.g. "MyApplication.exe" to "MyApplication_OLD.exe"), download the new version into the application folder (named "MyApplication.exe"), notify the user that an update has occured which requires a restart of the application, and then end. When the user restarts the application, it will be the newer version that starts - this version checks for and deletes the old version.

Doing an auto-update that automatically restarts the application after an update like this is very tricky (it involves kicking off another process and then ending its own process before the auto-restart process kicks in). I've never had a user complain about having to restart the app.

Answer 2

Ok, first of all, if one of the installer/updater products out on the market fits your need, you should probably use those. That being said, I've had the pleasure of building a system like this myself not long ago. Yes, our installer/updater included two parts on the client side so that:

~ Part A would connect to the servers where the latest version is stored and published; if a newer version of Part B was available, it would download it and kick it off

~ Part B would focus on installing/updating the actual application (and could download and install updates to Part A).

Aside from that, I'd recommend always considering the following 4 operations in the installer/updater:

• Install and Uninstall

• Update and Rollback (i.e. undo the last update)

The Rollback one is critical when your users have a system that automatically updates overnight.. if an update every messes up, they can rollback and continue working while you fix the issue.

Finally, the installer/updater should try and be agnostic about the application it installs/updates, so that, when that application changes, the installer/updater system is impacted the least possible amount.

Answer 3

I coded an updater for an app I worked on in C++, but the general structure would be the same.

1. App checks an URL for version number or other identifier change
2. App pulls down new updater app from network
3. App runs new updater app (which could include code for unforseen changes in update process), and then app exits
4. New updater waits for app to exit, then downloads and installs new "stuff", etc.

This worked pretty well for us, and as it always downloaded a new "updater" as the first thing it did, we could handle some funky new things that might not work otherwise.

Answer 4

Wrote our own automatic update software. So here's my tip... Don't do it!! Of-course this all depends on your specific scenario, but here are the problems that my company encountered:

• Difficult to support on an ongoing basis, especially if you target Win2k through to Windows 7.
• Challenges with permissions. WinVista/7 UAC can be a real pain.
• Flexibility is a requirement, but you won't be able to foresee all issues. For example, starting/stopping services, launching files etc. are all tasks that you MAY want to do for your automatic updates, but which you won't necessarily foresee.

The problem with our software is that we needed a lot of flexibility and support on all Windows platforms. The solution we wrote worked fine, but didn't scale and started to fail when Windows versions changed or weren't quite like those in our lab. We ultimately bought software and I recommend you do the same. If you are interested, we bought a product called AutoUpdate+ (link text).

Answer 5

Here's an open-source solution I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible.

So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you make the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.

Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.

This boild down to one DLL, less than 70kb in size.

More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/

Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)

I plan on extending it more when I'll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn't support.

Answer 6

ClickOnce didn't work well for us. We install the database on our customer's server. The database on their end needs to be updated before we do an update. We have a lot more than just 2 or 3 customers, so doing ClickOnce for our application is not really the best idea, unless I am missing something important about ClickOnce.

What I did, was add a field to the database for version number. On our ftp site, I have a versions folder that has a folder for each version number of our application. Inside that particular version's folder, we put a zip file with the setup.exe and the msi file that the setup.exe will launch. All the pre-reqs are downloaded from the vendors site to ensure that our FTP site isn't getting hit with huge downloads (.Net 3.5 when we moved to it). When our application launches, it checks the field in the database for the version number, and if it's different than the current versions assembly version, it will connect to the ftp site, download the zip file from that new version's folder, unzip it, and execute the setup. This will install newer versions of .Net or any other requirement we may have added, then launch the MSI to install our application and all the user has to do is click next a few times.

Answer 7

This zip contains the source code for a word search generator tool that includes AppUpdater boilerplate code.
http://cid-842434ebe9688900.skydrive.live.com/self.aspx/Games/WordSearchGenerator-src-v1.3.zip

Look for the 3 source modules that have "AppUpdater" in the name.

It is very simplistic and works only for single-assembly applications. No MSI file. Just an EXE. The philospohy is that update checks happen automatically, but updates are installed only after user confirmation.

The way the updater works:

It loads an XML document from a URL that contains the "latest version" information, as well as a second URL where the actual new version is located. The updater logic verifies the signature on the XML doc, but you may not care about that. The updater then compares the current version against the latest version, and can tell the application if an update is available. The updater also handles the replace-in-place problem.

In this model, there are three "lifecycle stages" of an app during an update. In the normal course, the app checks for updates, and then runs as normal. At some point the user may confirm that they want to install the available update, and the Updater downloads the app to a temporary location, then starts a process using that newly downloaded exe. The updater logic then exits the first process. The second process, based on the command-line-arguments given to it by the first process, realizes that it is a newly downloaded copy and needs to replicate itself. It copies itself to the original location (specified on the command line), starts that exe, and exits. The third process starts as normal, sees that there has been an update, and deletes the temp exe copy. It then runs as normal, including checking for updates. It will find that there are no updates, and will then just run as normal. That covers the operation of the update-in-place logic.

This is all handled by these lines in the constructor of the Windows Form or WPF Window:

  _Updater = new AppUpdater.SimpleAppUpdater(_MyManifestUrl);
  _Updater.Startup(App.CommandLineArgs);

The check-for-update problem is also handled by a few lines of code in the constructor, that create and run a background worker thread:

  _Worker = new System.ComponentModel.BackgroundWorker();
  _Worker.DoWork += CheckLatest;
  _Worker.RunWorkerCompleted += CheckCompleted;
  _Worker.RunWorkerAsync();

The CheckLatest is this:

    void CheckLatest(object sender, System.ComponentModel.DoWorkEventArgs e)
    {
        lock (_Updater)
        {
            if (_Updater.UpdateIsAvailable) // Checks for update
            {
                // can update a textbox (etc) here.  Be careful of InvokeRequired.
            }
        }
    }

The completed event is this:

void CheckCompleted(object sender, System.ComponentModel.RunWorkerCompletedEventArgs e)
{
    if (!e.Cancelled && e.Error == null)
    {
        lock (_Updater)
        {
            // only display the about box if there is an update available.
            if (_Updater.HaveCheckedForUpdate && _Updater.UpdateIsAvailable)
            {
                // do whatever you want here.  Eg, pop a dialog saying 
                // "an update is available"
                About about = new About();
                about.Message= "An update is available";
                about.ShowDialog();
            }
        }
    }
}

It works from WinForms or WPF apps. I guess it would work from console apps as well, but I have never tried it.

Creating the (possibbly signed) manifest file is a separate task, not covered here.

Thinking about it, this might better be packaged as a base class AutoUpdatingForm (for WinForms) or AutoUpdatingWindow (for WPF). But I never took that step.

Answer 8

If you're using .Net why not just use ClickOnce? It will do everything you're talking about out of the box and requires almost zero setup.

Answer 9

Ten years ago I wrote an auto updater (not in .NET), but the gist of it was that the application had a version id that was checked on startup. In this case the app queried a database table that had the current version and if the running version was less than the current version, the user was prompted to download the latest version. The same thing could be accomplished by checking a URL.

Answer 10

One of the solution I have yet to try is to have an installer that can run in silent mode.

The application call the server and if it needs to update, it downloads the last installer then runs it with a silent or an update flag.

It has a lot of benefits :

• flexibility : you can do anything you would do for a normal install
• no extra package : the installer and the update are the same thing
• if you uninstall then reinstall, you can handle rollbacks
• the update is a separate process, so it can launch the app when the install is complete
• you have tools to handle vista UAC