C # Deploying ClickOnce for Windows Services?

Question

What are some guidelines for deploying a Windows service that needs to be updated?

I have a Windows service that I will deploy, but beta testing may require some debugging and newer versions. What is the best way to handle this? Ideally, I would like to find a ClickOnce-style deployment solution for Windows services, but I understand that this does not exist. What is the closest I can get for ClickOnce for a Windows service?

Answer 1

The simple solution I'm using is just to stop the service and x-copy the files from the bin folder to the service folder.

A batch file, to stop the service and then copy the files, should be easily folded.

Net stop myService xcopy \\myServerWithFiles\*.* c:\WhereverTheServiceFilesAre net start myService 

Answer 2

I would suggest using the plugin approach on this, that is, using the Proxy Design Pattern .

Using this template, an independent thread can check the contents of the folder for updates. You will need to use ShadowCopy to deploy the assembly. When your service-thread update encounters a new version of your service, it should unload the current production assembly and download the new version without stopping the service itself. Even more! Your service should never notice the difference if there is no violation code in your assembly.

Answer 3

I have a system that we use at work here that seems to work well with services. Our deployed system has about 20-30 services at any given time. At work, we use a product called TopShelf, which you can find here http://topshelf-project.com/

Basically, TopShelf handles many things related to the service. Install, uninstall, etc. All from the line cmd service. One of the very useful features is the ability to run as a console for debugging. You create one service, and with another cmd line launch, you can run it as a console to see the result of the service. We have added one special feature to this software that allows us to pre-configure profiles. Basically, our profiles configure a few things, such as logging, resource allocation, etc., so that we can control all this without re-issuing any code. All we do is run a command, for example

D: \ Services \ ServiceName.exe Core.Profiles.Debug or
D: \ Services \ ServiceName.exe Core.Profiles.Production

to get different logging configurations.

Our build script creates install.cmd and uninstall.cmd scripts for each of our services that we do is copy the files to the server and run the script. If we want to see the debug output, we stop the service and double click on exe, and we get the console to read all the output.

Another thing that the top panel uses, which we don’t use because it is not needed, is the concept of shelving (there is documentation on this website for this). This allows you to update the service without having to restart it, but you still need to manually copy the files if you do not create an automated system for this.

However, my suggestion, if you need 100% service availability, is a redundant system. Regardless of how you configure your service for updates, you cannot avoid a hardware failure, which will lead to downtime without an automatic failover system. If this system were in place, my recommended upgrade strategy would be to disable 1 node, update, test, enable, turn off another node, update, test and enable the second node again. You can do this, of course, with a simple script. It may be a more complex system than you need, but if you cannot use the service offline for a simple restart that takes 5 seconds, you really need some kind of system to solve the hardware problems, because I can guarantee that it will happen eventually.

Answer 4

Since the service has been running for a long time, using ClickOnce style deployments may not be practical - since ClickOnce only updates when the application starts. Usually, the service starts only when the machine reboots.

If you need to automatically update the service, the best option might be manual code in the service, but I would see problems with almost any solution: for most installation processes, some level of user interaction will be required (if only to bypass UAC), so I can’t imagine that this will lead to an answer that does not imply that at some point the registered user is turned on in front of the screen.

One idea that might just work is to deploy an active directory (or similar equivalent). If your service is deployed using a standard MSI-type installer, AD allows you to easily upgrade your application as part of a computer policy. I suspect that you will have to force the server to update the AD policy (by rebooting or using gpupdate from the console), but other than that it should be a deployment with shutdown.

Answer 5

I would suggest creating a regular installation project and adding a Windows service project project to this installation project.

See http://support.microsoft.com/kb/816169 for more information.