Windows Service & App.Config changes

You may also like to see:

Create Windows Service Step-by-Step Guide

Recently I was working on windows-service, which contains scheduling functionality reports sends to the subscriber.

For step-by-step guide to create new windows service read this post.

Windows-service contains the config settings for time interval to send the reports. I changed WindowsService.exe.config after installation but I noticed it was not getting updated. So I searched and found some interesting facts, which I want to share with you.

If you have one of following question in your mind:

1. I changed app.config while the application is running. But the application does not read the change, unless I restart the application. What should I do?
2. Do you have to restart a windows service if you change the app.config?

Then YES!!!, config changes not get implemented until you restart the windows service because DotNet framework will read the app.config once, at the start of application. That is why you have to restart the application to update the settings.

Now you must be thinking why it is not getting auto-refresh?

let see the reasons step by step:

what exactly will it need to do if it has to update the settings?

First, it will have to know that the app.config file has changed. This can be done by registering file change notification. so any change in file notify the application.

Once it get notified that app.config has changed then it has to notify all the components or modules using these settings, but issue is how come service know which module is currently using these settings.

Now if we say we register all components using these settings and notify these application. What these application needs to do?

To take effect of updated changes i.e, new value for a key, the component will have to “restart” itself. This means, the component needs to be able to flush the old config data, stop current execution as it was using old value and restart it with refresh values.

This is not always possible. Take binding policy as an example. If the old binding policy says I want version 1.0.0 for assembly A, the new policy says I want version 2.0.0 for assembly A. There is no way for .Net framework to recover with the new binding policy, if assembly A version 1 is already loaded.

Only those part of application can be refreshed which have state-less effects or their effect can easily be removed. like Cache size on change of cache size, you can re-size the cache (and still keep the data), or simply remove the old cache and start a new cache fresh.

In general when the app.config changes, the only safe way to make sure all components are consistent is to restart the application.

Asp.Net has the web.config change detection built in. It watches changes on web.config. Once it detects a change, it will shutdown the old application, and starts a new application which causes data loss for currently logged-in users.

Since .Net framework won’t provide the config data refresh feature, if this is important to you, you have to roll your own implementation.

Fortunately the Enterprise Library folks understand there is a need for this. They developed “Configuration Application Block” in the latest Enterprise Library release.

You may also like to see:

Create Windows Service Step-by-Step Guide