Why is Castle.Windsor resolving my disposed views?

Question

I have some existing MDI WinForms code which uses Windsor to resolve the child forms like this :

private void Show<T>() where T : IMdiChildView
{
    var view = _windsorContainer.Resolve<T>();
    view.Closed += (sender, args) => _windsorContainer.Release(view);
    view.Show(this);
}

The views are registered an an IWindsorInstaller like this :

public class ViewInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(Classes.FromAssemblyContaining(typeof(IView)).BasedOn(typeof(IView))
                                  .WithServiceAllInterfaces().LifestylePooled(1));
    }
}

The reasoning for LifestylePooled(1) being that when a child view is open, there should be only one. This may be the wrong way to use LifestylePooled? It doesn't happen with LifestyleTransient, but when one form exists we don't want any new ones to be created and there when each form is disposed, they just sit around in the container taking up memory.

The simplest view has no other dependencies, but when we close it and subsequently call the Show<T>() method again, Windsor returns the disposed form which results in an ObjectDisposedException when the MdiParent tries to show it.

I'm beginning to think that the usage of Windsor in this project is flawed (I already recognise that it's being used as a ServiceLocator), but even if this particular usage isn't recommended, the behaviour seems difficult to explain.

Answer 1

LifestylePooled is probably not what you want.

First it doesn't prevent more than maxSize objects being instantiated. It simply will maintain up to maxSize hot objects ready to go.

Second releasing a pooled component may (depending on how many objects are in the pool) simply make that object available for reuse.

Pooled is useful where you have objects that are expensive to construct and which cannot be singletons but which can be reused by different components.

One way to address your requirements would be to use LifestyleTransient and do the reference counting yourself. Increment in Show. Decrement in Close. Release when your ref count hits zero. It's not the best way to use a container but since you're already down the Service Locator anti pattern road it may be acceptable.