Good practices for handling multiple config files with DI frameworks

In my current solution I have 18 projects and most of them have their own configuration files (app.config or web.config). Each project uses single shared BLL assembly. I'm using Autofac to handle dependencies but haven't come with a decent way of managing my configuration. Configuration entries are roughly the same, but values are different. Some projects use custom config secions and some are not.

I ended up with:

1. Create single autofac bootstrapper class to register all dependencies except configuration file wrappers.
2. Create separate assembly (referenced by all projects) with IConfiguration interface.
3. Create each project's own implementation of IConfiguration.
4. Bootstrap dependencies in each project's approp开发者_如何学Goriate place via shared bootstrapper.
5. Register project's own IConfiguration implenentation separately after bootstrap registration.

I'm very new to Autofac and DI in general and striving to find a good balance between complexity and extensibility.

Are there better ways to manage configuration files?

Thank you.

In Autofac you use Modules for this purpose. Groups of related components are encapsulated in a module, which is configured by the programmatic API.

Autofac's XML configuration has support for modules, so once you've decided to use one in an applicaiton, you can register the module (rather than all the components it contains) in the config file.

Modules support parameters that can be forwarded to the components inside, e.g. connection strings, URIs, etc.

The documentation here should get you started: http://code.google.com/p/autofac/wiki/StructuringWithModules

HTH

Nick

As a rule of thumb I only put dependency configuration in .config files if they represent something I want to be able to change without recompiling the app. By default, I have none such configurations.

I don't (yet) know about AutoFac, but in Castle Windsor, you can mix .config and programmatic configuration of the container, and that's what I usually do: I have a few dependencies configured in .config because I want to be able to change them without recompilation, but the rest is registered in code (often by convention).

The way I've approached a problem similar to yours is by making a separate library that contains a specialized container - this sounds a lot like your approach. This specialized container encapsulates all the common configuration of dependencies.

In each application I have an even more specialized container that derives from the shared container and overrides whatever configuration it needs to override.

The way I understand your description, that approach seems to be not too far apart from yours, but do yourself a favor and move as much configuration as possible out of XML and into code - it actually becomes more manageable that way.