How to enable the use of Unity in a mutli-project solution

Question

In the new WPF project (VS2010), I am using Unity 2 for the first time. In this project, I use the following structure:

Decision

WPF project

Class Library1

Class Library2

Class Library 3 ....

Registering various types with Unity is done in a WPF project using the following snippet:

IUnityContainer container = new UnityContainer() .RegisterType<IObjectContext, ObjectContextAdapter>() .RegisterType<IConnectionStringProvider, ConnectionStringProvider>() .RegisterType(typeof(IRepository<>), typeof(Repository<>)); 

Say now that I would like to get the <Orders > repository containing the constructor allowed in Class Library1. Apparently, the container is not known in other projects!

How can I do it?

Answer 1

I basically agree with Chris's answer, but I think the configuration files are unclean (especially for Unity), so here you will find a solution that allows you to use the runtime configuration without circular references. We are going to do this using 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 its 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 need to create a container and apply these registries.

 var container = new UnityContainer(); new RegistryForSomeClassLibrary().Configure(container); new RegistryForAnotherClassLibrary().Configure(container); 

You now have a fully configured container instance without any configuration files.

Answer 2

To use multiple projects in the same script with the same UnityContainer, you need a “generic” project that contains your UnityContainer and exposes it in such a way that all other projects can access it.

i.e.

WPF project

Class Library 1

Class Library 2

Class Library 3

Shared library (UnityContainer lives here)

To avoid project circular dependencies, I would recommend instead of <Unity development time configuration via the configuration file instead of the run-time configuration (as in your example). Otherwise, your shared library will have to reference projects that contain all the types that it resolves, and these projects, in turn, will depend on the shared library (since this is supposed to be where you can expose the UnityContainer instance). You can make it work using configuration at runtime, but I have not tried this; I know that development-time configuration works the way I did several projects using such a model.