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.