i’m not the one you need to convince here… most people think i take IDisposable and memory management in general too seriously
(coincidentally, these are the same people who don’t believe me when i say we always disable application pool recycling and _don’t_ run into issues with it… go figure )

It obviously is not.
NTRP fixes symptoms – not causes.
You may use no IoC Container at all, and still NSB not releasing it’s components means you will have leaks nonetheless. You may have handlers that obtain database connection. If you don’t release them, they won’t release the connection. They may have finalizers but before finalizers run, you may already be out of connections and your application may die (yes – there are more problems here than these related to NSB, but it’s just an example ).

And that problem would touch not only Windsor. AutoFac also tracks some transient components, StructureMap does so with nested containers… dunno about the rest.

you’d have to ask Udi that… though i suspect he’ll tell you that the NoTrackingReleasePolicy is already “good enough”

Can’t NServiceBus limit scope of container by using nested container per unit of work?
This may be my motivation to finally take a look at NSB, which I’ve been meaning to do for quite some time.

You have quite a neat solution here. So far I went along with NSB’s behaviour in my app, because I don’t have my own code that would rely on this feature of Windsor, but I think I will switch to your solution – even if I don’t rely on it one never knows if some other stuff (like facilities) also does not.
Thanks for sharing it.

BTW I would change the check to catch NSB namespace only:
if (!instance.GetType().FullName.StartsWith(“NServiceBus.”))

Either way, the approach above will still work, as long as you overwrite the ReleasePolicy _after_ you configure NSB.

I do think the act of changing the ReleasePolicy of a passed-in container to the NoTrackingReleasePolicy is wrong… the consequences it can have on existing code can be pretty big and people really need to be aware of this

Well, it actually does. The relevant part in WindsorObjectBuilder class is

public WindsorObjectBuilder(IWindsorContainer container)
{
Container = container;
container.Kernel.ReleasePolicy = new NoTrackingReleasePolicy();
}

and it is called from ConfigureWindsorBuilder

public static Configure CastleWindsorBuilder(this Configure config, IWindsorContainer container)
{
ConfigureCommon.With(config, new WindsorObjectBuilder(container));

return config;
}