On occasion you have need for an application that will run all of the time on a workstation or server, whether anyone is logged into that workstation, or perhaps running in the background. For those requirements you’ll want to create a Windows Service.
There are a few things you have to keep in mind when creating a Windows Service. The first, and most important is that there is no user interface. Because Windows Services run in the background, even when no user is logged in, most times (especially when running on a server) there is no one to display a user interface to. As such, things like MessageBoxes and Forms are not allowed. Instead, if you need to log messages and the like it’s recommend you use the Event Logger. (For more info see my series on event logging, it started on January 16 of this year and ran to the 19th, http://shrinkster.com/p6d).
The next thing you will want to decide is how you’d like your service to start. You have three choices; in Manual mode (which is the default) either a user or some program event must start the service. In Automatic mode, windows will automatically kick off the event for you, and start it running when Windows itself starts up. Finally, in Disabled mode, nobody can start it until the start up type is changed.
Now you need to think about security, what permissions will your service need? LocalService is the most secure, it gets sandboxed on a local station and any access to insecure tasks, such as writing to the hard disk, are restricted. This is a good choice when you want to create an app that monitors something on the box and logs it’s output to the event log, but needs little other in the way of resources.
For a server you might wish to bump up to NetworkService. This will allow communication with other PCs on the network, but still manages any potentially harmful access to the machine.
If you need unlimited privileges, you’ll need to set your security to LocalSystem. I encourage you to really think about this before you pick LocalSystem as your level, as you open yourself up to severe vulnerabilities if anyone were to hack your code. However I do recognize there are some cases where it’s the only way to make it work, or perhaps you are in a situation where it’s safe to do so (perhaps your machine is not on the internet).
The final, and default choice is User. With User, you pass in a user id and password, and your service has the same permissions as that user. The ideal situation would be to create a special user account just for this service, and set the permissions just high enough to get the job done, and no higher. Also you’ll likely want to setup an ID with a non-expiring password. If you omit a user id/password then the person who launches the service will be prompted for a valid user id/password at run time, probably not a desirable option.
You should also be aware that debugging a windows service is very different from your typical debugging, whether you are used to WinForms or ASP.Net coding. We’ll cover debugging in a post of its own later in this series.
Just as debugging is different, so is installation. Because of its nature a Windows service has to be installed, you can’t just copy it and run it. Fortunately Visual Studio makes it easy for you by generating a setup project you can use. Again, we’ll cover that later in the series.
OK, you now have all the background you need under your belt, tomorrow we’ll start generating some code!