.NET: centralizing split configuration

Question

Let's say I have a large .NET solution that has some data access projects that are used by a couple of other project types, like a console app and a web app. I want them to both be able to use the data access project, but the data access app has to grab configuration from its configuration file...so web.config for the web project and app.config for the console/service apps. This makes me have to maintain configuration in two or more separate config files, something that I don't like. What's the best way to get them into a centralized location?

I want it to still be lightweight, so a configuration database might be overkill. I'm thinking maybe a centralized config file that gets copied by the build process to web.config/app.config when the respective projects are built, but I wanted to make sure I'm not missing another best practice somewhere. I've also thought about machine.config, but I'd like to isolate configuration as much as possible so as not to potentially disrupt other applications on a given machine. And, by using machine.config, I'd have to figure out a way to get the build script automatically updating that file remotely.

Answer 1

That model works pretty well--most of our more significant apps are multi-headeded beasts with multiple web and command line apps that need to share some of the same configuration info. One good trick is to abuse the configSource property of the configuration elements to break out the "central" pieces from the application specific pieces.

Answer 2

A couple of possible solutions:

1. If all your solutions are going to be deployed to the same place (e.g. a web server/farm), you could use the machine.config file to store common data access config such as connection strings.

2. Split your common configuration out into a separate config file (e.g. common.config) and use the configSource attribute in the main config files to point to the common one. If your using some kind of source control, this should let you share the common file between projects, so one change to it would be picked up by all that use it.

Answer 3

How about this:

• Define your "dev/staging/production" settings in the config file of the data access project

• Let the clients (apps) define what kind of settings they want to use, e.g.

... = DataAccess.UserGateway.Create(DataAccess.Config.Dev);

and the string constants for the names of the different configs are only defined in one place - the DataAccess module.

On the other hand, I am a lot for copying configs at build/deploy-time - it's so clean.