IoC containers, fluent interfaces circular references

I have an app which contains views which inherit from IView (project A)

I have Windsor IoC Container as a Singleton in another project (project B)

Project A has a reference to project B, and makes a static call to the container to resolve the concrete type for particular views

If I use XML configuration to configure my container then all is well and good.

If I try to use the fluent interface for configuring my contrainer I get a circ开发者_开发百科ular reference, as I now need project B to reference project A in order to specify the interfaces and concrete types

So what is the best way to go about this using the fluent interface?

EDIT:

Project A has this on app startup :

IoC.Instance.Start(); // this configures the container from config
IoC.Instance.Container.Resolve<IBootStrapper>().Start();

Where IoC is a static class defined in Project B

Best is to design your application around dependency injection (constructor injection) and configure the container at the startup path (composition root) of your application. Ideally, your project B should not have a dependency on the DI container itself, or at most have some bootstrapping code in the project that allows creating the configuration for that project.

When you register the container in the startup project (possibly project A in your case) you won't have a circular reference.

UPDATE

In the comments you explained that your Project B project is solely for IOC bootstrapping. There is nothing wrong in having a bootstrapper project, because this will allow you all the other projects completely clean from the use of any IOC container. You would typically use a bootstrapper project if you have multiple libraries that are reused by multiple applications (for instance a business layer that is used by a web app, a web service and a windows service).

The bootstrapper project should however, only bootstrap 'static' dependencies of the reusable projects. There is no sense in configuring things that change per application project. Next, since the bootstrapper is in itself a reusable project, you don't want it to have a dependency on one of your application projects, since that would be the part you will be swapping. What's the use of having a reference to a ASP.NET web app when running a Windows Service? That would be yucky.

A bootstrapper project is especially useful when having multiple application projects, but this doesn't mean that you can't use it in a single application solution. Still the same rules apply here, since you would end up with circular references, as you already noticed.

In other words, the solution is simple: Let the bootstrapper only bootstrap dependencies for the projects below and not the application project. If however, the application project is the only project you have, you don't need a bootstrapper project; it won't work.