We need to create a windows service that has the ability to self update.
Three options spring to mind,
a second service that manages the retrieval, uninstallation and installation of the first service.
Use of some third party framework (suggestions welcome. I believe .NET supports automatic updating for windows forms apps, but not windows services)
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
I use option 1. The updater process gets updated very rarely these days. It uses an XML file containing the details of where to get the files from (currently supports SVN, working on adding NuGet support) and where to put them. It also specifies which ones are services and which ones are websites and specifies the name of the service to use for each project.
The process polls the source, if there is a new version available it copies it down to a fresh version numbered directory and then updates the service. It also keeps 5 copies of each update making it easy to roll-back if there is a problem.
Here's the core piece of code for the updater which stops the existing service, copies the files over, and then restarts it.
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.