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

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 2

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 3

Unfortunately there is no Sparkle or update-engine for .NET. There is the Updater Application Block for .NET released by Microsoft, that's your best bet if you don't want to completely roll your own solution (there's still a bunch of code you'll need to write though).

Answer 4

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

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

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.