retrieve all configuration settings that are loaded by the configuration manager

Is there any way to enumerate through all settings to get the values that have been loaded by the configuration manager? Maybe I'm being dense here, but I can't find a way to enumerate through the settings that are contained within a section group.

I have a WCF service which is a designed to allow the calling system to pass in request objects which define the operation to be performed on the server. The service loads assemblies dynamically at runtime (like a plug-in model) and determines which object can answer the request. I am looking for a way that I can send a request to "give me all your config info", and the service can return the loaded information. I'm interested in what has been loaded into memory and is being used vs. what values are specified in the actual config file (the config can be replaced without affected anything in memory until a restart).

There's a SettingLoaded event that I might be able to use to keep track of them, but this seems far-fetched.

Any ideas?

[UPDATE] The main purpose for this question is that I need a way to determine the difference between the settings contains within an assemblies physical .config file vs the setting that are compiled into the assembly as part of the "default" config.

I can't just use the physical config file as the starting point for the comparison, because there may not b开发者_开发百科e a config file present, or the config file may only provide one of the values, causing the others to use their default value.

Perhaps I'm misunderstanding your question, but to me the only settings that are guaranteed to be key/value pairs are the AppSettings, which you can get to via the ConfigurationManager.AppSettings property.

It sounds like you're basically wanting to have a registration system for plug-ins. It also sounds like you're trying to diff what's in memory vs. what's loaded because you want to detect when the registration has changed without restarting?

If those are true, one option is to create your own registration xml file and use the FileWatcher class to get an event when the file has changed then you can reload the registration info.

Maybe the solution here is a change in process/procedure so that all config-based settings are to be explicitly provided via a config file. This could be ensured by always providing a breaking or "known-bad" value for any setting's default value. This would ensure that valid values must be provided by a config file. This approach would allow a comparison of values using the config file as the comparison source.

The drawback to this approach is that all config settings have to be merged into the primary assembly's config file in order for the values to take effect.