I’ve got a windows service which is going to be be updated ~ fortnightly
I’ve already got all the useful code in a DLL, the service is just a couple of simple Start and Stop methods which map to identical methods in the DLL.
I use a console app to develop/debug the DLL so I was wondering; Instead of the service referencing the DLL directly and requiring an uninstall/reinstall every time I do an update, is there any downside to using the service to wrap the console application?
Which is to say, instead of…
Private MyService as IMyService
Sub Start()
MyService = New MyService()
MyService.StartAsync()
End Start
Doing something like…
Const ServiceExecutablePath As String = "C:\Blah\MyService.exe"
Private MyService as Process
Sub Start()
MyService = Process.Start(ServiceExecutablePath)
End Start
That way, if I want to publish, All I need to do is stop the service, replace the executable (and relevant DLLs) and then start it again.
I haven’t quite worked out how to do a graceful shutdown yet. The console app listens for the CTRL C interrupt and calls MyService.Shutdown(Graceful:=True) (A blocking call). Should I try to emulate the same from within the service or is there a better way?
You don’t need an executable for this. You can dynamically load a DLL when you bring your service up.Either do it manually (see this link), or use something like MEF to load it for you.
Another easy approach is to use TopShelf to host your service. With TopShelf, you develop and run your service as a console application. When you pass the argument install to the console app, it will be installed as a service. It makes easy to replace as you don’t need installers.