views:

86

answers:

2

My project contains WinForms, WPF, and Windows Service programs running on users' office desktop PCs. I want these applications to periodically check for new versions available at specific URL, automatically download new versions and replace themselves with new versions without attracting any user attention (keeping in mind that users may run Windows from XP to 7 and work using non-privileged account (which can be part of active directory)). Alternatively the whole update package has to be able to be distributed as an unattended-installed MSI package.

Any recommendations on implementing this?

+1  A: 

You are out of luck - sadly all solution suck. Your best bet (i.e. what I am doing) is have one application check whether it is out of date regularly and signal that to the user. Now, in my case "Wndows Service" means "with a user logged in on anothe computer pretty much all the time controlling the service", so I have someone to actually alert. If that does not work, you will have to reimplement something like the windows update service - there sadly is no predefined way to do that.

No user attention does not work at all, btw. - installation / update of windows services will have to be done with adminsitrative rights, even if those come from the priviledges of a windows service making the updates. Dirty issue whatever you do that.

I would go with an MSI - this way corporate users can roll that out via their software management (which can install priviledged), whatever they use there (there are multiple), and (home) end users just can install it with admin priviledges, like they do with every other software. Maybe do a web service call on every start checking for a new version on a central server.

TomTom
+1  A: 

This is certainly a problematic area with no easy solutions, especially because every solution has a number of drawbacks leaving no clear winner.

One option is to replace only .dll files. This prevents signing of the assemblies (since you're not updating the executable file itself) and requires the application to be structured in a way so that almost all of the application logic resides in dlls. The benefit is that you can have the exe itself check for updates and download them when available, but this is only feasible if the dlls are stored as data elsewhere (e.g. an application plugin folder in appdata).

Another option is to use a Windows service that runs with local administrative rights to download and install the updates. This can happen without user intervention, even for another Windows service afaik. The trick here is to not leave the update service running, but start it from one of the actual applications (either on startup or when it is closed) and then have the service stop itself after installing any updates, in order to avoid bogging down users systems with yet another update service.

Last, you should seriously consider dropping the "completely unattended" part. Users might find intermittent startup delays to be an issue and communicating what you are doing does not cause any harm. I particularly like the solution that displays a dialog on startup saying "new version found - install (now) (on exit) (later)", giving me complete control over whether I want the delay or not. Some applications (like every poker client I know of) need to be in sync with server-side software and do not give you this option, but still show the "update in progress" dialog so that I know what is going on. As long as the installation is automatic I wouldn't worry about the prompt.

Morten Mertner
'I particularly like the solution that displays a dialog on startup saying "new version found - install (now) (on exit) (later)"' - This can be a good idea only in case of personal use by a power user. In enterprise environment it is generally a bad idea to ask a user for technical decisions.
Ivan
Ivan: Agreed. Enterprise updates should be centralized and automatic.
Morten Mertner