I have seen the same question asked many times.
“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?”
.Net framework will read the app.config once, and never touch the app.config again. That is why you have to restart the application to pick up the change.
Why does not .Net framework detect that app.config has changed, and refresh all the config data?
The reason is simple, this is not possible in general.
Let’s use Raymond’s “imagine this could be done” logic here.
Say .Net framework did implement this feature. What exactly will it need to do?
First, it will have to know that the app.config file has changed. This can be done by registering file change notification.
Once it detects that the app.config has changed, it needs to inform all the componenets that read the app.config.
We get a problem right here. How will .Net framework knows which component reads the app.config? Short of a registration mechanism, this is not possible.
Say we do have a mechanism for app.config readers to register in .Net framework. When .Net framework detects change in app.config, it will notice each component that app.config has changed. Now what those components should do?
In order for the new change to take effect, the component will have to be able to “restart” itself. This means, the component needs to be able to flush the old config data, and data/behavior based on the old config data, then read the new config data, and start fresh from there.
This is not always possible. Take binding policy as an example. If the old binding policy says I want version 1 for assembly A, the new policy says I want version 2 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 a subset of config data can be refreshed. Those include config data with no stateful effect, or effect can be easily removed. Cache size is a good example. 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. This is the approach .Net framework takes.
ASP.Net has the app.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.
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 can get Enterprise Library from MSDN
Scott Densmore’s blog (http://blogs.msdn.com/scottdensmore) has several entries for configuration application block. Be sure to check it out.