What is the features your DI Container of choice has that others don't have?
I'm sorry this is a very long question. I'm looking for help from people passionate about DI Containers enough to read it through. Thank you for you time!

There has been numerous topics on SO, discussing what DI Container for .NET is best and what the options are. Most of these questions are from back 2009, and DI Containers landscape appear to have changed since than.

Now don't get me wrong. I'm, strongly convinced that it does not matter *that much* which DI Container to choose as long as you give it some thought and choose one. By the way this is true not only about DI containers, but also about many other cross-cutting concerns.

However within an organization it is better to settle on a particular technology, so that developers can gain expertise on this technology and can apply it across the projects. This does not mean that aforementioned technology should be set in stone for all projects. It simply means, that if *there is no compelling reason* for a project to chose one DI container over another, no time is spent discussing which container must be used, because a "preferred" recommendation is set up front.

I'm trying to figure out what can make a good recommendation, as per above. Again: it is not possible to choose one-fit-all technology, but it should be possible to choose a "default" one.

This leads me to comparison criteria of DI containers. There are [numerous][1] [benchmark][2] [comparisons][3] of different DI Containers in the net. However some people things, that [performance should not be choosing criteria][4] for a DI container. There are [anecdotal evidences][5] though, that performance could matter.

[This guy][6] put together a set of comparison criteria for different DI containers, it's a very good starting point, however there are a lot of DI containers features that are not on the list. Features like ability to support AOP-style interception and ability to register object instantiation via delegates immediately come to mind. Support for container hierarchies is another feature that is not mentioned on the list and there are many more. Support of ASP.NET MVC is usually easy to add but it's nice if it's provided out of the box or with an out-of-the-box extension.

As of the moment of writing there are more than a dozed of different DI Containers. In my mind I roughly categorize them like this:

**Dinosaurs:** 

 - [Castle.Windsor][7]  
 - [StructureMap][8]  
 - [Spring.Net][9]

'Dinosaurs' does not mean 'bad'. It means that they have a very long history, thus very mature, may have modern features but the core was developed before .NET 3.5 came around which affects their architecture. They are all available via NuGet.

**LinFu:**
 
 - [LinFu][10] - LinFu is set aside in my mind. Unlike many other projects mentioned in my list, this one didn't see many recent releases. [This article][11] makes it sound like the author has given up on the project, although I'm sure this is not true. 
 - [Hiro][12] - Same article, introduces this experimental container that pre-compiles object instantiation/injection code so that resolution time becomes comparable to the time without using DI at all. Sounds interesting, but I haven't heard any reports of production use, and (may be my fault), this is the only project that did not work out-of-the box for me when I got is with NuGet. 

**Modern:**

 - [Unity][13] 
 - [Autofac][14] 
 - [Ninject][15] 
 - [LightCore][16] 

These containers are based on .NET 3.5 and do not give an impression of "aged" in any way. Unity has a drawback of being over-engineered. I don't agree with the author of [this article][17], that the simplest way to work with the decorators in Unity is obtuse, in fact many other containers implement it exactly this way. But I do strongly agree, that whenever there is a need to customize Unity to do something that it is not doing out of the box it is a major pain. 

LightCore looks nice, fast and stable, however not nearly enough documentation and it is not [obvious][18] how to implement aforementioned decorators with it. [Anyone][19]?

All these are available via NuGet.

**Minimalistic:**
 
 - [Funq][20] - limited number of features but easy to setup and fast.
 - [Munq][21] - like Funq, but with wired-in support for ASP.NET MVC and WCF
 - [Petite][22] - Really tiny one - fits in one .cs file. Flexible lambda based registration, but but not much else.
 - [MicroIoC][23] - minimalistic container for Windows Phone 7 

Some of these are available via NuGet.

**Those I've never heard of anyone using:**

 - [S2Container.NET][24] 
 - [PicoContainer][25] 

They are mentioned on Scott Hanselman's [page][26] listing different DI Containers available. I've never came across them in any other context.

These are not available via NuGet.

Another criteria is availability of commercial support. I understand that [support][27] for Castle.Windsor is available, but I think this is about it. Ninject mentions paid support on the [contribute page][28], but no email or link is given, and since this support is most likely is not backed up by an established company it may not be reliable.

My thinking currently, that Castle.Windsor is appealing because of maturity and  availability of commercial support. Unity is appealing because is backed up (although not supported) by Microsoft. Autofac and Ninject are appealing in modern, easy to use, extend and understand department, with Ninject is winning in the easy to get started category.


Now, getting this out of the way we are coming close to my real question. To be able to choose one DI container over another it is necessary to have comparison criteria. Obvious ones are feature supported. Since there is no "official" list of DI features, I'd like you to answer the question in the title: If you prefer a particular DI, what features of this DI that are important for you are not to be found (or not as easy to implement/use) in other DIs? 

Thank you in advance for all the input!


  [1]: http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
  [2]: http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison
  [3]: http://philipm.at/2011/0808/
  [4]: http://stackoverflow.com/questions/5315562/di-ioc-container-performance-benchmark-comparison/5315675#5315675
  [5]: http://omaralzabir.com/munq-is-for-web-unity-is-for-enterprise/
  [6]: http://blog.ashmind.com/2009/10/12/net-di-ioc-frameworks-revisited/
  [7]: http://www.castleproject.org/container/
  [8]: http://structuremap.net/structuremap/
  [9]: http://www.springframework.net/index.html
  [10]: https://github.com/philiplaureano/LinFu
  [11]: http://plaureano.blogspot.com/2009/04/introducing-hiro-worlds-fastest-ioc.html
  [12]: https://github.com/philiplaureano/Hiro
  [13]: http://unity.codeplex.com/
  [14]: http://code.google.com/p/autofac/
  [15]: http://ninject.org/
  [16]: http://www.lightcore.ch/
  [17]: http://www.beefycode.com/post/Decorator-Unity-Container-Extension.aspx
  [18]: http://twitter.com/#!/andrewsav/status/114174144064667648
  [19]: http://twitter.com/#!/andrewsav/status/114174317671100416
  [20]: http://funq.codeplex.com/
  [21]: http://munq.codeplex.com/
  [22]: https://github.com/andlju/Petite
  [23]: http://microioc.codeplex.com/
  [24]: http://s2container.net.seasar.org/en/index.html
  [25]: http://docs.codehaus.org/display/PICO/Home
  [26]: http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
  [27]: http://www.castlestronghold.com/services/support
  [28]: http://ninject.org/contribute
What is the features your DI Container of choice has that others don't have?
===

I'm sorry this is a very long question. I'm looking for help from people passionate about DI Containers enough to read it through. Thank you for you time!

There has been numerous topics on SO, discussing what DI Container for .NET is best and what the options are. Most of these questions are from back 2009, and DI Containers landscape appear to have changed since than.

Now don't get me wrong. I'm, strongly convinced that it does not matter *that much* which DI Container to choose as long as you give it some thought and choose one. By the way this is true not only about DI containers, but also about many other cross-cutting concerns.

However within an organization it is better to settle on a particular technology, so that developers can gain expertise on this technology and can apply it across the projects. This does not mean that aforementioned technology should be set in stone for all projects. It simply means, that if *there is no compelling reason* for a project to chose one DI container over another, no time is spent discussing which container must be used, because a "preferred" recommendation is set up front.

I'm trying to figure out what can make a good recommendation, as per above. Again: it is not possible to choose one-fit-all technology, but it should be possible to choose a "default" one.

This leads me to comparison criteria of DI containers. There are [numerous][1] [benchmark][2] [comparisons][3] of different DI Containers in the net. However some people things, that [performance should not be choosing criteria][4] for a DI container. There are [anecdotal evidences][5] though, that performance could matter.

[This guy][6] put together a set of comparison criteria for different DI containers, it's a very good starting point, however there are a lot of DI containers features that are not on the list. Features like ability to support AOP-style interception and ability to register object instantiation via delegates immediately come to mind. Support for container hierarchies is another feature that is not mentioned on the list and there are many more. Support of ASP.NET MVC is usually easy to add but it's nice if it's provided out of the box or with an out-of-the-box extension.

As of the moment of writing there are more than a dozed of different DI Containers. In my mind I roughly categorize them like this:

**Dinosaurs:** 

 - [Castle.Windsor][7]  
 - [StructureMap][8]  
 - [Spring.Net][9]

'Dinosaurs' does not mean 'bad'. It means that they have a very long history, thus very mature, may have modern features but the core was developed before .NET 3.5 came around which affects their architecture. They are all available via NuGet.

**LinFu:**
 
 - [LinFu][10] - LinFu is set aside in my mind. Unlike many other projects mentioned in my list, this one didn't see many recent releases. [This article][11] makes it sound like the author has given up on the project, although I'm sure this is not true. 
 - [Hiro][12] - Same article, introduces this experimental container that pre-compiles object instantiation/injection code so that resolution time becomes comparable to the time without using DI at all. Sounds interesting, but I haven't heard any reports of production use, and (may be my fault), this is the only project that did not work out-of-the box for me when I got is with NuGet. 

**Modern:**

 - [Unity][13] 
 - [Autofac][14] 
 - [Ninject][15] 
 - [LightCore][16] 

These containers are based on .NET 3.5 and do not give an impression of "aged" in any way. Unity has a drawback of being over-engineered. I don't agree with the author of [this article][17], that the simplest way to work with the decorators in Unity is obtuse, in fact many other containers implement it exactly this way. But I do strongly agree, that whenever there is a need to customize Unity to do something that it is not doing out of the box it is a major pain. 

LightCore looks nice, fast and stable, however not nearly enough documentation and it is not [obvious][18] how to implement aforementioned decorators with it. [Anyone][19]?

All these are available via NuGet.

**Minimalistic:**
 
 - [Funq][20] - limited number of features but easy to setup and fast.
 - [Munq][21] - like Funq, but with wired-in support for ASP.NET MVC and WCF
 - [Petite][22] - Really tiny one - fits in one .cs file. Flexible lambda based registration, but but not much else.
 - [MicroIoC][23] - minimalistic container for Windows Phone 7 

Some of these are available via NuGet.

**Those I've never heard of anyone using:**

 - [S2Container.NET][24] 
 - [PicoContainer][25] 

They are mentioned on Scott Hanselman's [page][26] listing different DI Containers available. I've never came across them in any other context.

These are not available via NuGet.

Another criteria is availability of commercial support. I understand that [support][27] for Castle.Windsor is available, but I think this is about it. Ninject mentions paid support on the [contribute page][28], but no email or link is given, and since this support is most likely is not backed up by an established company it may not be reliable.

My thinking currently, that Castle.Windsor is appealing because of maturity and  availability of commercial support. Unity is appealing because is backed up (although not supported) by Microsoft. Autofac and Ninject are appealing in modern, easy to use, extend and understand department, with Ninject is winning in the easy to get started category.


Now, getting this out of the way we are coming close to my real question. To be able to choose one DI container over another it is necessary to have comparison criteria. Obvious ones are feature supported. Since there is no "official" list of DI features, I'd like you to answer the question in the title: If you prefer a particular DI, what features of this DI that are important for you are not to be found (or not as easy to implement/use) in other DIs? 

Thank you in advance for all the input!


  [1]: http://www.codinginstinct.com/2008/05/ioc-container-benchmark-rerevisted.html
  [2]: http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison
  [3]: http://philipm.at/2011/0808/
  [4]: http://stackoverflow.com/questions/5315562/di-ioc-container-performance-benchmark-comparison/5315675#5315675
  [5]: http://omaralzabir.com/munq-is-for-web-unity-is-for-enterprise/
  [6]: http://blog.ashmind.com/2009/10/12/net-di-ioc-frameworks-revisited/
  [7]: http://www.castleproject.org/container/
  [8]: http://structuremap.net/structuremap/
  [9]: http://www.springframework.net/index.html
  [10]: https://github.com/philiplaureano/LinFu
  [11]: http://plaureano.blogspot.com/2009/04/introducing-hiro-worlds-fastest-ioc.html
  [12]: https://github.com/philiplaureano/Hiro
  [13]: http://unity.codeplex.com/
  [14]: http://code.google.com/p/autofac/
  [15]: http://ninject.org/
  [16]: http://www.lightcore.ch/
  [17]: http://www.beefycode.com/post/Decorator-Unity-Container-Extension.aspx
  [18]: http://twitter.com/#!/andrewsav/status/114174144064667648
  [19]: http://twitter.com/#!/andrewsav/status/114174317671100416
  [20]: http://funq.codeplex.com/
  [21]: http://munq.codeplex.com/
  [22]: https://github.com/andlju/Petite
  [23]: http://microioc.codeplex.com/
  [24]: http://s2container.net.seasar.org/en/index.html
  [25]: http://docs.codehaus.org/display/PICO/Home
  [26]: http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx
  [27]: http://www.castlestronghold.com/services/support
  [28]: http://ninject.org/contribute