What would be the best way to persist user-editable settings for a Windows Service?

Question

I'm developing an application that's going to be implemented as a Windows Service and I was wondering what'd be the best way to deal with the different settings (at User and Application level). The thing is, I'm not completely familiar (yet) with all the available options, so in principle I'm favoring .NET's own System.Configuration (ConfigurationManager.RefreshSection("appSettings") seems tempting), although I'm still failing to wrap my head around the whole picture, namely, where is the app.config file being stored for a given service, so on.

So my question for you guys is, what would be the best way to store user-editable configuration details for a given Windows Service? Thanks everyone in advance for the feedback.

Answer 1

Hmmm...'user-editable' configuration settings for a Windows Service...

The thing to keep in mind is that the Windows Service runs in the background, so it does not have a direct way for users to interact with it. What I've done to get around this is to create a separate front-end application that communicates with the Windows Service using WCF. In this way, the 'user-editable' configuration settings are persisted as part of the front-end application's settings, not the Windows Service. The settings are simply communicated to the Windows Service using a series of WCF messages as the user changes them.

In my case, I've even added a NotifyIcon to my front-end application and added logic so that the app can be removed from the taskbar when it is minimized. It works the same way Task Manager does when you turn on the 'Hide When Minimized' option. This gives the user the illusion of interacting with the service directly, even though it is two completely independent processes.

EDIT:

In response to your comment, WCF is simply a messaging API. Messages are usually defined as classes decorated with the DataContract and DataMember attributes. The ServiceContract and OperationContract attributes define the WCF service interface. Once these are defined, creating and hosting the WCF service inside your Windows service is easy. And if you have Visual Studio 2008, creating the client-side proxy is a snap as VS2008 can automate it for you.

Once all this is done, your front-end app simply instantiates an instance of the client-side proxy and invokes the methods on that proxy. As each method is invoked, the WCF framework takes care of serializing and sending the message to the WCF service for it to act on. It then serializes any response, including exceptions, back to the proxy. From the perspective of the client-side, e.g., your front-end app, you've simply invoked a function. That's the beauty of WCF! It's very analogous to socket programming, except you don't have to manage the connections. WCF takes care of all that plumbing for you.

Of course, all this assumes you can at least use .NET 3.0. If you are using Visual Studio 2008, you're in good shape. Here are a couple of tutorials to help you get started:

• WCF Essentials
• WCF Services

Once you have the basic concepts down, I would recommend looking at Juval Lowy's website. There are a lot of free WCF-related downloads there that I find very helpful to look at, although it's a bit more advanced. Understand the WCF concepts first before delving too far there.

Again, the whole point of this is to help your users configure various aspects of your Windows Service. If you do not provide a front-end GUI to do this, I'm not sure how they'd do it short of manually manipulating the app.config file itself.

Hope this helps.

Answer 2

If you just need a single name/value dictionary to store your configuration parameters, then the app.config is the simplest answer. In your solution it's called "app.config", but when it's built it gets renamed to be the name of the executable + ".config".