I have the following problem:
We have an application that loads modules (add ons). These modules might need entries in the app.config (e.g. WCF configuration). Because the modules are loaded dynamically, I don't want to have these entries in the app.config file of my application.
What I would like to do is the following:
- Create a new app.config in memory that incorporates the config sections from the modules
- Tell my application to use that new app.config
Note: I do not want to overwrite the default app.config!
It should work transparently, so that for example ConfigurationManager.AppSettings
uses that new file.
During my evaluation of this problem, I came up with the same solution as is provided here: Reload app.config with nunit.
Unfortunately, it doesn't seem to do anything, because I still get the data from the normal app.config.
I used this code to test it:
Console.WriteLine(ConfigurationManager.AppSettings["SettingA"]);
Console.WriteLine(Settings.Default.Setting);
var combinedConfig = string.Format(CONFIG2, CONFIG);
var tempFileName = Path.GetTempFileName();
using (var writer = new StreamWriter(tempFileName))
{
writer.Write(combinedConfig);
}
using(AppConfig.Change(tempFileName))
{
Console.WriteLine(ConfigurationManager.AppSettings["SettingA"]);
Console.WriteLine(Settings.Default.Setting);
}
It prints the same values twices, although combinedConfig
contains other values than the normal app.config.
You can try to use Configuration and Add ConfigurationSection on runtime
EDIT: Here is solution based on reflection (not very nice though)
Create class derived from
IInternalConfigSystem
then via reflection set it to private field in
ConfigurationManager
Daniel's solution seems to work even for downstream assemblies I had used AppDomain.SetData before, but was unaware of how to reset the internal configuration flags
Converted to C++/CLI for those interested
If anybody is interested, here is a method that works on Mono.
If your config file is just written with key/values in "appSettings", then you can read another file with such code :
Then you can read section.Settings as collection of KeyValueConfigurationElement.
Daniel, if possible try to use other config mechanisms. We have been through this route where we had different static/dynamic config files depending on environment/profile/group and it became quite messy at the end.
you could try out some sort of Profile WebService where you only specify one Web Service URL from the client and depending on Client's details (you might have Group/User level overrides), it loads up all the config it needs. We have also used MS Enterprise Library for some part of it.
that was you dont deploy config with your client and you can manage it separately from your clients
@Daniel solution works OK. A similar solution with more explanation is in c-sharp corner. For completeness I'd like to share my version: with
using
, and the bit flags abbreviated.