I recently had the need to change the lifestyles of all components in a WindsorContainer (read on to the end if you want to know why). This turned out to be amazingly simple to do.

The problem was this: I had numerous components registered in a WindsorContainer, some of them as Singletons, some as Transients and yet again some as PerWebRequest. Configuration was even defined in numerous IWindsorInstallers, including some distributed XML files. I now needed to spin up a second container with the same configuration as the first one, except that the lifestyles should be all Singletons across the board.

This can be easily accomplished by implementing a custom IContributeComponentModelConstruction type. Here’s a simple example:

Consider this IWindsorInstaller:

public class FooInstaller : IWindsorInstaller

{

    #region IWindsorInstaller Members

    public void Install(IWindsorContainer container,

        IConfigurationStore store)

    {

        container.Register(Component

            .For<IFoo>()

            .ImplementedBy<Foo>()

            .LifeStyle.Transient);

    }

    #endregion

}

The important point to notice is that it registers the lifestyle as Transient. In other words, this container will always return new Foo instances:

var container = new WindsorContainer();

container.Install(new FooInstaller());

We can override this behavior by adding this custom IContributeComponentModelConstruction:

public class SingletonEqualizer :

    IContributeComponentModelConstruction

{

    public void ProcessModel(IKernel kernel, 

        ComponentModel model)

    {

        model.LifestyleType = LifestyleType.Singleton;

    }

}

In this very simple example, I always set the lifestyle type to the same value, but obviously we can write as complex code in the ProcessModel method as we would like. We can now configure the container like this:

var container = new WindsorContainer();

container.Kernel.ComponentModelBuilder

    .AddContributor(new SingletonEqualizer());

container.Install(new FooInstaller());

With this configuration we will now get the same instance of Foo every time we Resolve IFoo.

We did I need this? Because my application is a web application and I’m using the PerWebRequest lifestyle in a number of places. However, I needed to spin up a second container that would compose object hierarchies for a background process. This background process needs the same component configuration as the rest of the application, but can’t use the PerWebRequest lifestyle as there will be no web request available to the background process. Hence the need to change lifestyles across the board.