AppDomain and config section typing

Question

I have a Windows application in .Net 2.0 that uses several levels of configuration files. For reasons out of my control, the application consists of a Windows app (.exe) project and several DLLs, each of which has its own app.config file.

I have successfully figured out how to read the config file for each DLL, using (in C#)

ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);

This works just fine - I can confirm that I get a Configuration object from this method when pointed to the file path name of my DLL's configuration file ("foo.dll.config"). However, when I try to access a custom configuration section, I get an exception saying that the data type for my custom configuration section cannot be found.

What else do I need to do to get the typing information available to my code when loading a configuration file in this manner?

Answer 1

It's unfortunate but true: the way to handle this is to copy the configuration from the .dll.config files into the applications' config file. The only exception has something to do with the Settings system used in Windows Forms. I think that does the OpenMappedConfiguration for you, but I'm not sure.

I've never known why they didn't unify this in .NET 2.0 and solve the problem. Maybe I should ask.

---

Earlier in the day, I asked a question like this as relates to WCF, in the Oslo Forum on MSDN (http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044-b1f0-43ad72fb508d). As I was searching for a blog post or some other answer (as I said above, "maybe I should ask"), the answer to my Forum post arrived.

Long story short, and somewhat tongue-in-cheek, the answer is: they didn't fix this in .NET 2.0 because they were waiting for Oslo to solve the problem.

Without trying to avoid downvotes by making sense out of that, I'll just mention: Oslo will encourage models of applications and application components to be stored in a central repository. That will include models of per-instance configuration. The theory is that all such data would be stored in a single repository (at least per-system). So, no more question of where the configuration file is located it's all in one place. No more question of finding the assembly containing the configuration section metadata - the metadata is stored in the repository along with the configuration data.

Ask me tomorrow, and I may feel differently, but right now, I may be picking up the Oslo religion...