I am writing a configuration system in which the app.config file is dynamically constructed from various config fragments distributed across multiple locations. The system currently works as follows:
- Bootstrapper builds configuration file.
- Bootstrapper initializes new AppDomain with new config file as the configuration file.
- As a result, new AppDomain is configured to use new config file and all works fine.
We'd like to move away from this multiple AppDomain approach; it adds a layer of complexity, especially when it comes to unmanaged libraries and other legacy code.
In moving to one AppDomain, the workflow would change to:
- Bootstrapper builds configuration file.
- Bootstrapper merges the configuration file into its own configuration file.
- Bootstrapper refreshes its ConfigurationManager cache.
- Bootstrapper launches main app in the same AppDomain.
It seems that the ConfigurationManager caches sections in memory. So for example, if I read the AppSettings before step #3, I have to call: ConfigurationManager.RefreshSection("appSettings"); In fact, I have to make sure that any section that has been used by the bootstrapper, is refreshed.
I am able to iterate over all of the config sections in the new config file and force refresh them, but, this forces the configuration manager to load any assemblies referenced in the config file. I'd like to defer this if possible. If there a way to invalidate what the ConfigurationManager currently has in memory?