How to do resolving using Unity in a mutli-project solution - inversion-of-control

Question

In a new WPF project (VS2010) i 'm using Unity 2 for the first time.
In this project i use the following structure:
Solution
WPF Project
Class Library1
Class Library2
Class Library 3 ....
Registering the different types using Unity is done in WPF Project using the following snippet:
IUnityContainer container = new UnityContainer()
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
Let's say now that i would like to get the Repository<Orders> constructor-injected resolved in Class Library1.
Apparently the container is not known in the other projects!
How would i do that?

Answer 1

I mostly agree with Chris' answer, but I think config files are icky (especially for Unity) so here's a solution that will allow you to use runtime config w/o circular references. We're going to do this with registries.
Create an Infrastructure project that will contain IConfigureUnity.
public interface IConfigureUnity
{
public void Configure(UnityContainer container);
}
Each of your class library projects will be responsible for implementing this interface to register it's own classes.
public class RegistryForSomeClassLibrary : IConfigureUnity
{
public void Configure(UnityContainer container)
{
container
.RegisterType<IObjectContext, ObjectContextAdapter>()
.RegisterType<IConnectionStringProvider, ConnectionStringProvider>()
.RegisterType(typeof(IRepository<>), typeof(Repository<>));
}
}
Then in your WPF project you'll need to create the container and apply these registries.
var container = new UnityContainer();
new RegistryForSomeClassLibrary().Configure(container);
new RegistryForAnotherClassLibrary().Configure(container);
Now you have a fully configured container instance w/o any config files.

Answer 2

To have multiple projects make use of the same UnityContainer in this scenario, you need a "common" project that contains your UnityContainer and exposes it such that all other projects can access it.
i.e.
WPF Project
Class Library 1
Class Library 2
Class Library 3
Common Library (UnityContainer lives here)
To avoid circular project dependencies, I'd recommend using Unity design-time configuration via a configuration file instead of run-time configuration (as you have in your example). Otherwise your Common Library will have to reference the projects that contain all of the types it resolves and those projects, in turn, would be dependent on the Common Library (since that is presumably where you would expose the UnityContainer instance). You may be able to get it to work using run-time configuration, but I have not tried that; I do know that the design-time configuration works as I have done a few projects using a model exactly like this.