How would you centralize configuration across multiple projects?

Question

I have a solution with about 10 projects with read-only config. They are web applications, windows services, console apps, etc. All projects except for one are on the same server. Each project has 3 environments - dev, test, and production. So there are 30 different sets of configuration, each one with a decent number of settings. It's cumbersome to keep the config consistent across every app and environment.

I've noticed most of the configuration is common across each project, so I was thinking it would be good to centralize the config in some way. I read somewhere that a WCF service might be a good approach. I thought maybe a library containing a hard-coded static class might actually work OK - despite having to compile to change config. Ideally the config should come out of an actual .config file.

How would you go about centralizing config for multiple projects?

Answer 1

If you want to maintain the standard configuration interface, take a look at the ProtectedConfigurationProvider. This provider lets you store your configuration data outside of a standard configuration file, encrypt it however you like, or redirect requests for configuration in any way you see fit:

• Redirecting Configuration with a Custom Provider - Wrox
• Implementing a Protected Configuration Provider - MSDN
• Protected Configuration - Blayd Software

The beauty of this approach is that nothing changes in your existing applications. They don't need to know where their configuration is stored. The retrieval of configuration data is isolated in the provider. You can store it in a central file, store it in a database, or access it via a web service. If you change your mind, you only have to update your provider. Everything else stays the same.

Answer 2

You could certainly set up a WCF service that has a simple operation to retrieve configuration settings, taking in the application and environment as a parameter; you could then have the service load up the correct config from a file and return it to the caller. It might be a good idea to do nested configuration files, so that common settings are only defined once at their most generic level.

A potential issue could arise if the WCF service is down when starting up one of your apps -- you would need to decide if there is default config/caching of the previous copy for this situation, or if you just don't allow apps to start up if they cannot connect.

Another thing to consider, though, is the benefit of .config files in .NET in that when they change the app can respond; you may want to have a callback WCF service that notifies clients if their configuration has been updated on the central server, so they can request a new copy and update themselves if necessary.

Answer 3

Since they are (almost) all on the same server you could consider providing defaults in the machine.config and/or central web.config files. I'm not normally a fan of using/changing these file but they are there... in \Windows\Micsrosoft.NET\Framework<version>\Config\