IoC configurations - one file/assembly in solution or one file per executing assembly?

Question

We're wondering what the best practise for registering types in a IoC-Container is.

What would be arguments for and against the following principles:

Principle 1: Only one Assembly my.project.DependencyInjection

• Seperate assembly for dependency injection
• One class (f.e. UnityConfig.cs) where all types of the whole solution are registered
• my.project.DependencyInjection references alot of projects to register their types

Principle 2: A IoC container configuration class per executing assembly

• Every executing assembly has their own UnityConfig.cs file
• Only the needed types of this assembly are registered in the respective UnityConfig.cs file

What's your stance in this?

Thanks in advance for your opinions and arguments

Answer 1

Like most of my answers on here: it depends.

For small projects having one central location to configure all your IoC mappings is fine.

For larger projects, I like to have each Module (not necessarily an assembly, but could be a group of assemblies with related purpose) declare its own IoC mappings.

So, my advice to you: Don't look for a rigid rule that works in all cases. Do what works for your case and, as always, allow room for change.

Answer 2

I'm familiar mostly with Castle Windsor so this answer is biased towards what this library offers, although it should apply to all IoC containers.

Windsor uses installers for grouping component registrations. In most of the projects I work on there is one installer per module, plus additional installers for general concerns. Installers are not supposed to be reusable, so if you have an application with multiple entry points you should have different installers for each composition root. Having component registration code in each module would unnecessarily make it dependent on the container.

The comments in the blog article I linked provide some more arguments on this subject.