Amen.

Found Castle Windsor and used that for a few years until about a year ago when I switched to AutoFac.

Autofac has good support for nested/child containers and the ability to automatically release all dependencies which I find very handy for managing units of work. Autofac is also faster at object construction (from what I’ve read http://www.clariusconsulting.net/blogs/kzu/archive/2009/04/17/141951.aspx).

Take Ruby on Rails crowd – they took implicit relying on features of their framework and turned it into an art. It’s hardly a bad thing if it lets you crank the code faster.

@Darren – I don’t think there’s _any_ container that does not support interception or child containers. Unity is hardly the source of innovation in IoC space, unless you consider laying GUI on top of IoC configuration an innovation.

Now to the real question.
On my previous project I used Unity and I hated it (http://kozmic.pl/archive/2008/12/03/unity-framework-and-the-principle-of-the-least-surprise.aspx).

Currently I use AutoFac (hey Nick) and while I miss certain features of my favorite container (especially in terms of integration with NHibernate and WCF) it pretty much works as expected and does the job, so there’s no bad thing I could say about it.

When I’m in charge I usually use (surprise) Windsor, which I just know very well, it is _very_ extensible and can be easily customized and tweaked for needs of my application.

there’s definitely an implicit dependency on that kind of behavior, yes

But i’ll take that over having my components knowing about the lifecycles of their dependencies and whether or not they can or need to be disposed. They really shouldn’t have to know about it, and because of this behavior in Windsor, they don’t have to.

And last one: usage (and often over-usage) of sophisticated container features could be a sign of building application that depends on DI infrastructure. And even if I don’t use my container API _explicitly_, if I rely on features like automatic disposal, there is an implicit dependency.

I think you’re right about the loyalty assessment. I definitely feel that pull to think my IoC tool is the “best” but I’d definitely like to hear more from others about what their container can do that mine can’t. I’ve noticed that if enough conversations like these occur, that the project maintainers tend to add such features (like Func dependency resolution – stolen from AutoFac and just added to SM last week!).

–Jeff

We use autofac at the moment and it just sits there quietly doing it’s job. I could completely replace it in an afternoon but see no compelling reason to do so.

In fact, I’m not sure I could change to a different IoC and retain the same functionality. Now, I haven’t looked at the others lately and I know I’ll get hit as soon as I say this, but months ago I didn’t see the some features that I use in Unity (Interception, child containers, etc.) in the others.

As we’ve matured in our use of IoC, though, container choice has become a non-issue because we hardly see the container. We only touch it directly in the few cases where we need to apply an exception to our convention-based registration, or when we use things like interception. Otherwise, we’ll keep the resolution of classes hidden away behind the Common Service Locator.