How to use SimpleInjector in a multi project solution without creating circular references

Question

I’m starting a multi project solution that will have more than one entry point, for example a Windows Service, ASP.NET web sites, WebApi Controllers etc. I’ve settled on SimpleInjector as it’s very fast and I do not need any advanced features.

My understanding is that SimpleInjector should be centrally configured on start-up. Starting with the following basic example set of projects

• NS.Controllers
• NS.Core.Data
• NS.Core.Data.Model
• NS.Web
• NS.WindowsService (assume this will not always be running)

With multiple entry points where should the bootstrapping of SimpleInjector go and can/should it be handled centrally (in which case the configuration process would need to reference all projects to be able to set up all solution classes)?

Should I have a global instance (such as NS.Global.Container) that references none of the other projects and each entry point is responsible for adding its own instance requirements on startup (gracefully handling duplicate registrations such as NS.Core.Model)?

Should I be looking to use the ResolveUnregisteredType event to handle registrations on request?

Am I simply lacking some schoolboy knowledge?

UPDATED:

Links provided by Steven in the comments below give thorough answers to this question.

Where to locate Ninject modules in a multi-tier application

How to initialize Ninject in a class project part of an mvc site

Answer 1

Each entry point should have its own bootstrapping container.

NS.Web should have one, since that is a website (I'm assuming here). NS.WindowsService should have one, since that is .exe (service).

The other projects look like class libraries, so they would not have a bootstrapping container.

In theory, yes, you can define a partial bootstrapping container in each class library which you can then use in the main bootstrapping container (in the web/service projects), to make life easier. In the partial container you would then do the bootstrapping for the components of that class library.

Answer 2

Why not using IPackage interface? You can make packages in each module and then in each entry point just call container.RegisterPackages();. For example, all configuration for NS.Core.Data will be located in NS.Core.Data.dll and so on. Then, it will be useable in both NS.Web and NS.WindowsService. In NS.Web just configure types that are specified to it and then call container.RegisterPackages(); and so on. Your NS.Core.Data package may looks like this:

public class CoreDataPackage : IPackage {
    public void RegisterServices(Container container) {
        container.Register<ISomeService,SomeImplementation>();
        // etc...
    }
}