How do you manage .NET app.config files for large applications?

Question

Suppose a large composite application built on several foundation components packaged in their own assemblies: (database reading, protocol handlers, etc.). For some deployments, this can include over 20 assemblies. Each of these assemblies has settings or configuration information. Our team tends to like the VS settings editor (and the easy-to-use code it generates!), and the application vs. user distinction meets most of our needs.

BUT....

It is very tedious to copy & paste the many configuration sections into our application's .xml. Furthermore, for shared components that tend to have similar configurations across applications, this means we need to maintain duplicate settings in multiple .config files.

Microsoft's EntLib solves this problem with an external tool to generate the monster .config file, but this feels klunky as well.

What techniques do you use to manage large .NET .config files with sections from multiple shared assemblies? Some kind of include mechanism? Custom configuration readers?

FOLLOWUP:

Will's answer was exactly what I was getting at, and looks elegant for flat key/value pair sections. Is there a way to combine this approach with custom configuration sections ?

Thanks also for the suggestions about managing different .configs for different build targets. That's also quite useful.

Dave

Answer 1

You use one master config file that points to other config files. Here's an example of how to do this.

Answer 2

We created an AssemblySettingsConfig class that acts like ConfigurationManager, but loads a .config for each individual assembly. So the application has a .config, and any DLLs it references have their own .config files. Has worked out well so far.

Answer 3

A great way to manage large sets of configuration is to create custom configuration sections. Phil Haack discusses this very nicely in this article Custom configuration sections in 3 easy steps

Answer 4

My preferred method is to use MSBuild, if you right click on a project and click 'unload' a new menu option will pop up that says 'edit '. Select that and it'll open up the project file so you can edit it, scroll down until you find a commented out section that is called "AfterBuild".

You can then add something like:

<Target Name="AfterBuild">
    <Delete Files="$(TargetDir)$(TargetFileName).config" />
    <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

This will replace the application config with one named [Release|Debug]app.exe.config. So you can maintain separate configurations depending on how the project is built.

But a quick and dirty option (if you don't want to play with msbuild) is to just maintain separate config files and then define which one you want to include, like this:

<appSettings configSource="Config\appSettingsDebug.config"/>
<roleManager configSource="Config\roleManagerDebug.config"/>

And if you are doing an asp.net application, microsoft provides a great utility called "Web Deployment Projects" that will allow you to manage all of this easily, click here

Answer 5

Set up build configurations for each of your deployment/testing environment and use separate config files based on each build configuration.

ScottGu has a nice post about this and it works great. The only quirk we have is that we need to make sure that the config files (web.config) are checked out for edit from TFS before each build so that it can be copied over.