Best way to handle multiple config file instances?

Question

We run a complex system written in C#.NET 3.5, consisting of 20+ websites, 10+ windows services and various scheduled tasks and helper apps.

Each of these is bundled with one or more of our framework and business logic DLL's. These DLL's have extensive config settings, and this has turned into a nightmare where we're maintaining over 40 config files for multiple instances of the same class libraries.

We don't register our DLL's in the GAC for various reasons: 1) We like the flexibility of quickly rolling out changes to selective projects without rebuilding the whole system or causing unnecessary downtime. 2) Some instances of the DLL's require slightly different configs; for example some projects use different connection strings, notification e-mail addresses and so on.

We experimented with the AppSettings file/configSource attributes in Web.config/App.config, but those only work with relative paths, not across projects. We considered saving the defaults in machine.config but this is a mission, being too cluttered and full of important stuff unrelated to our projects.

Our current "solution" is to use our own config file format, which first checks for a config in the current project's "bin" folder, and if that doesn't exist it loads from a hard-coded central location. This allows us to override settings when necessary but use the default settings the rest of the time.

Ultimately what we want is to have each class library default settings in a central location, and then each instance could have an optional config file which only overrides those settings that differ from the default.

Is there a suggested, industry-standard way of solving this problem in .NET ?

Answer 1

If this is all within the same company why don't you just store the configs in the database? I believe the Enterprise Framework even has adapters you can plug in to do just this.

I know at our company since we had sites running in webfarms we would store the config in the db, then if we needed to change something we would have a db script update the config. no need to push to the sites, just had to restart the site or touch the web.config to force the reload.

Another solution we had for other items were to use a database that housed key value pairs along with other types of config data so that we could also easily change things across our website / windows forms projects that used the same components.

So I guess what I'm saying is if they are all within the same company / sphere of influence such that you could use a database that is central to them all just use the DB.

Don't polute the registry.

Answer 2

I would use OpenExeConfiguration (http://msdn.microsoft.com/en-us/library/ms224437.aspx) and have each app/dll open 2 configs, the first would be the defaults, the second the overrides.

You could keep the defaults in that "central" location, granting read access to all your apps to it, and have the local configs reside near your apps.

Answer 3

How did you deploy these web sites and applications, were these modules in your system running in the same machine, and were these modules invoking the DLLs from a specific directory?

If in the same machine you could use configuration file, if in a server farm you may need database as Joshua metioned before.

If you just need to override some configuration section to a common configuration file, you could load your defaults from the central location first, and load your specific configuration in each projects then modify the Configuration object in the runtime.