Making your Application Automatically Update Itself
I've always thought it was the height of classiness when an application lets me know that there's a new version available. Even little applications with no installer like Lutz's Reflector update themselves automatically.
There's lots of ways to implement an automatic update check in your application, and many products that say they'll do it automatically.
From my point of view, there's a number of levels of "coolness" in auto-updating. Now, all this assumes you're NOT using ClickOnce.
- Add a "Check for Update" menu that just launches the default browser like www.foo.com/update.aspx?version=184.108.40.206 where 220.127.116.11 is your own Main Assembly Version. Then the requested page just lets them know if they've got the latest or not.
- You can get your app's version number via System.Windows.Forms.Application.ProductVersion() or System.Reflection. Assembly.GetExecutingAssembly(). GetName().Version.ToString(). Whew!
Cooler would be:
- Add a "Check for Update" menu that retrieves via a programmatic HTTP GET some XML from www.foo.com/update.aspx?version=18.104.22.168. Then report INSIDE your app if the user needs to upgrade.
Cooler still would be:
- Bonus points for checking once a day/week/month for updates, silently, gracefully.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
I would be interested to find out what products do it for you (because implementing code was a PITA).
I think the coolest would be to have a central place (a la Windows Update), where vendors can register their updates. Then you'd have one system component that would check for updates and let you download and install.
Now VendorUpdate.com is a good idea...
Do all of the above while remembering to work with proxies (especially of the authenticating varienty) and also cope with standard users (i.e. not administrators), UAC and the fact that UAC might get declined.
(Reflector tries to auto-updates itself, fails on the proxy and deletes itself. Possibly not in that order.)
PS. A timely not on handling proxies...
Don't forget the BITS API, which can easily be used within .NET. Jason Clark wrote a nice article in MSDN Magazine about it here (http://msdn.microsoft.com/msdnmag/issues/03/02/bits/).
Thanks to the info from Scotts Blog above, I have implemented the following.
When my application starts one of the first things it does is retrieves "CurrentVersion.xml" from my website. Compares the users current version with the version reported in "CurrentVersion.xml". If a new version exists, I launch a separate application named "AppUdater.exe" which downloads the Current version of my Client application, using System.Net.WebClient DownloadFile.
This all works great. The problem is that my AppUdater.exe is static, and I would like it to perform different actions based on the version downloaded (ie. rename files, delete files.. standard stuff an Update application would do.) I am looking for some ideas on how to make my "AppUpdater.exe" more dynamic.
Any suggestions would be great.
I have configured ClickOnce to check for updates in the background. When a new version is detected the user is prompted to restart and install (saving all data first). They can always defer the restart until later if not convenient at that moment.
Seeing as how the app is only like 70k total, they barely see the bar for the updater.
Ever heard of personal firewalls, ever heard of all the Windows crap built in XP SP2 that makes your app look bad as if it was trying to suck you your DNA?
Well that's what happens in practice if you try to do some whatever HTTP GET from your own application.
Give me a break.
Sometimes I just want to get something done and come back and do the update later.
So, I created a separate launcher exe that checked a webservice for a list of current files: if the list of files on the server differed from that on the client (determined by the hash of each file), then it'd download the necessary files, but only those. This had several benefits: We didn't need an installer for anything other than the launcher. If we only updated a single dll, then that was the only dll that needed to be sent to the clients. And should a user be boneheaded and delete an assembly, the application would heal itself.
To speed things up we compressed and decompressed the dlls (through the same web service compression utility we used for all webservice calls over a certain size).
The whole thing worked exceptionally well and was by far one of the more enjoyable tasks on the whole project...
Firefox's extensions panel is neat. It tells you which extensions have updates and a button next to each to update. No nagging update notices.
Retrieving information on the latest version, HTTP GET-ing XML, no problem.
However what I don't get is "what" then gets downloaded to perform the "update?"
Is it a .msi or setup.exe that effectively performs an automated installation as if the user had downloaded your application's setup installer and double-clicked it? Won't the running (old) application need to be closed down to do this?
Kenny Kerr states "Window Clippings will perform the upgrade in-place," does this mean it just downloads an executable or a DLL and simply overwrites the old one? How does it do this if it's actually running?
Sorry for perhaps not understanding the "obvious," I just need clarification so I'm not barking up the wrong tree.
Comments are closed.
I am still thinking through the design but am probably going to implement your "cooler still" level with an addition of showing the revision list when asking the user if they want to update.