Service and program interaction

I am developing a very basic windows service in C#. Apart from the service I also need to develop a program which will be used to set various parameters for the service.

As the service and program will be running in different processed by different users how do I tell the service that parameters have changed?

One way that I am considering is saving the parameters to a configuration file and then using ExecuteCommand method to indicate that settings have changed. The service will then read them from file.

Another option is to use pipes to send the actual data to service and service takes care of saving to them.

While the first option is easier to write the second one seems to be b开发者_高级运维etter.

Any suggestions or any other alternatives?

Thanks.

As you'll have to save those setting somewhere, you could have the service watch for the changes. If you write the settings to a config file, the service could use a FileSystemWatcher. If you write them to the registry, a registry watcher could be used (see SO).

But the ExecuteCommand is quite clean and well.

You can store the configuration parameters in a file and use a FileSystemWatcher from your service to watch for changes.

There are also various options for Interprocess Communication, but that's a more complex solution for a simple problem.

I had a small project that kinda did both. Using IPC it transferred settings over to the client, where the client modified the settings and sent them back. When the service received the new settings, it saved the settings using ConfigurationManager and updated itself accordingly. We went through great pains to allow the service to reconfigure without requiring a restart.

Update To fulfill Giorgi's request for more info:

We used Remoting, but you could and probably should use WCF. The positive side effect is you could change the binding to a routable IP and let remote users configure the service, if you wanted. That adds a security consideration, but you can handle that in WCF and remoting as you see fit.

I believe we could not just send ConfigurationElements or sections over a service, so instead we just created a simple Settings class and passed that back and forth. On the service side, we had the service translate the Settings class into an updated ConfigurationElement and save the config using ConfigurationManager. Worked fine for us, but I could see that being a massive pain if you have lots of configurable elements or complicated config schema. If it starts getting complicated, you might just want to use your own configuration API so you have complete control over types and lifecycle.

Finally, you need to make sure the part of the service that does the actual work checks for config changes at regular intervals when it's safe to reconfigure, and that processing that was already underway when configuration started will not be affected by changes. A simple way to do that is have the service stop processing when it receives a signal from client, and resume when the client says it's done.