views:

186

answers:

1

We need to create a windows service that has the ability to self update.

Three options spring to mind,

  1. a second service that manages the retrieval, uninstallation and installation of the first service.

  2. Use of some third party framework (suggestions welcome. I believe .NET supports automatic updating for windows forms apps, but not windows services)

  3. Use of a plugin model, whereby the service is merely a shell containing the updating and running logic, and the business logic of the service is contained in a DLL that can be swapped out.

Can anyone shed some light on the solution to this problem?

Thanks

+3  A: 

Just some thoughts I had.

1 seems problematic because you end up dealing with the situation you're trying to resolve because at some point the updater will need updating. 3 sounds good but if by "swapped out" you mean using some fancy reflection to load the dll during run time I'm not sure if performance will become an issue.

There is a fourth option where the service can spawn an update process which would allow it to update the update executable if necessary before running it. From there it's a simple matter of writing an installation app which the service will spawn just before shutting down.

Spencer Ruport
+1 We actually do have a self-updating .Net Windows service, and it does this when downloads a newer version: 1) Installs a new service if binary versions differ (could be just a configuration change though, in which case we just want to restart). 2) Spawn a helper process which: A) Stops old service, B) Starts new service, C) (if versions and not just configuration files) Remove the old service. This has been one of the trickiest areas to get right, and many bugs have been filed against this, and debugging has been a bitch :(
Hamish Grubijan
Firstly, if the new service is built against a newer .net Framework ... oh boy oh boy oh boy! We utilize some `.bat` files, it kind of works (with a restart sometimes), but it is fugly. Secondly, because debugging is a pain, LOG, LOG, LOG! The helper process should not write to the same log, so it should write to its own. `Trace.Writeln` is the easiest way to log, given that there is a proper entry in `app.config` file. Just remember to set auto-flush to true. Something this fragile better run slowly than without hints. Speaking of slowly, the helper needs to sleep for a few secs anyway.
Hamish Grubijan