Making your Application Automatically Update Itself
Sponsored By
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.
Cool:
- Add a "Check for Update" menu that just launches the default browser like www.foo.com/update.aspx?version=3.3.4.4 where 3.3.4.4 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=3.3.4.4. 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.
About Scott
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.
About Newsletter
Hosting By
Heh, Window Clippings 1.5 now supports "Check for Updates" in just the way you described it, providing a "Check for Updates" command in the notification icon's context menu. If a new version is available and you choose to upgrade, Window Clippings will perform the upgrade in-place and you will be able to continue working momentarily with little disruption. :)
I've deployed a departmental app via ClickOnce, but really, really don't like it. Its a 3d visualization thing that users open up to look at the shape of a particular coil every once in a while. The thing that's so annoying is every time you launch the app, a dialog sits there for several seconds while it (i'm assuming) checks the manifest on the webserver. If it were something that people opened once in the morning and left running all day, it wouldn't be that bad. But given the use case of this particular app, that couple of seconds is extremely annoying. Initially it was great as I was changing things a lot, but its settled out now, and I probably won't change the app again. </end rambling comment..>
I think Wix 3.0 gives "coolest" capabilities by updating/checking for updates based on an RSS feed from your server. (I realize that RSS is just an "HTTP GET some XML"...I wanted to add another acronym to the mix)
That is one timely blog post. I just finished coding it up yesterday for a kiosk-style application. Basically, you specify in the app.config when to check for updates, then the application contacts the server, checks for updates, downloads them, installs the app and restarts the app.
I would be interested to find out what products do it for you (because implementing code was a PITA).
I would be interested to find out what products do it for you (because implementing code was a PITA).
I agree that it's nice when applications let me know when there is an update. However, something that I think is uncool is apps that have their little "update checker" programs run at startup, or worse, have them sit in the tray. I'd much prefer to have the app check when I actually use the program (preferably in the background).
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.
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.
Dude, plus one on that. I hate the "custom updater" like the one that Adobe and InstallShield install.
Now VendorUpdate.com is a good idea...
Now VendorUpdate.com is a good idea...
Of course, if your users run as non-administrators, they don't have permission to install updates. So "Coolest" would be if an installer prompted the user for the appropriate credentials if the current user is not an admin.
And the "coolest" option:
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...
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...
So, how do you do this with .net? I'm somewhat interested in this after going through one ClickOnce certificate expiration, and anticipating another in October. (I might be able to diddle my certificate to keep the app going, but it's a hack.)
Great topic. I would love to see (er, hear) a Hanselminutes that addresses this.
Scott,
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/).
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/).
I agree that automatically downloading updates is annoying, however the Client/Server application I am currently developing relies heavily on the fact that all client must be using the same Client version.
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.
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'm using ClickOnce to deploy a medium-sized pupil assessment tracking application to schools in the UK. I love how updates can be installed by non-admin users, since everything goes into the user's %AppData% folder. Even better is the great VS.NET support for publishing new versions, I never have to touch any XML manifests or manually upload installers.
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.
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.
And minus 100 points if your app does an automatic update/install overnight and decides it needs to reboot your machine to finish. Hope you remembered to save before going to bed. (No, I'm not bitter about Windows Update at all)
I do this in a program that i have made in which we force installs to happen. basically it checks the version (via reflection) to a web service (down with http get!) in which i will just return whether the version is up to date or not, and if not it just automatically updates itself.
Seeing as how the app is only like 70k total, they barely see the bar for the updater.
Seeing as how the app is only like 70k total, they barely see the bar for the updater.
Yeah, I'm sick of starting windows and seeing pop-ups for java update, windows update, logitech update, virus update, and who knows what else. IMO, Windows needs a unified experience for this. An API for windows update maybe?
I gotta say, Kenny's Window Clippings was the smoothest auto update I've ever experienced...
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.
The new Restart / Recovery features in Vista should also help to enhance the user experience in update scenarios - let update your app and work on (quite) exactly where you left.
My favorite thing is how when you click Cancel/No/Whatever on Reflector's updater, it just deletes the entire Reflector exe for you and you have to download it again.
Sometimes I just want to get something done and come back and do the update later.
Sometimes I just want to get something done and come back and do the update later.
The way I did this at my last job was to force an update check at the launch of the application. The app was an internal WinForm 1.1 app, with a webservice backend, since the users were not all in the same location. Rather than politely asking if the users wanted to update, we actually could require that they always work in the latest release.
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...
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.
Interesting post.
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.
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.
If we are going to use HTTP GET and XML, it's kind of a no-brainer to leverage an existing feed format like RSS/Atom (see "appcasting") - updates/release notes can then be subscribed to with an existing reader etc.
Should have a look at http://www.devx.com/dotnet/Article/10045 i'm using something based on this for years now, including it in almost every program i write.
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.