This project got started as a result of a blog post from Jeremy Miller: It's time for IoC Container detente. His argument was that the embarassment of riches in the IoC/DI container space in the .NET world is actually making it harder to write libraries or frameworks that use a DI container. Since each container is different, library authors have to pick one, and thereby force their choice on the library's users.

A day or two later, Oren Eini sent an email to several authors of .NET IoC/DI containers as well as other folks at Microsoft, suggesting we should Just Do It. We all discussed it for a while and came up with the interface and assembly provided here.

The general approach was to provide a lowest common denominator that was still useful. As such, the interface here explicitly does not include anything about configuring a container or registering types. This configuration is where the various containers differ the most and offer the most individual value. It is expected that anyone using this library will have a bootstrapper method of some sort that sets up the initial container using whatever concrete container they choose.

Last edited Sep 30, 2008 at 10:03 AM by gblock, version 4


Bloudraak Sep 22, 2013 at 8:55 PM 
I don't agree with dot_NET_Junkie regarding the fact that the interface being useless. Having written LOB applications that use numerous 3rd party frameworks on the market, its often a mess trying to integrate every frameworks IoC/DI requirements. And that is the very thing this interface is trying to address, and does so rather well (provided those third party libraries support it).

For a LOB application, it also protects your investment. I've been developing LOB since the 90s and frameworks come and go. From that experience I often wrap 3rd party frameworks so they can be easily replaced in the future.

CurtD Aug 28, 2013 at 6:24 PM 
I actually find this to be a simple, but very powerful idea. It allows the use of IoC ServiceLocator implementation today and another tomorrow if you find a better one. It also lets you port classes and frameworks from one IoC to another without refactoring the ServiceLocator code. I would actually like to see P&P take the lead for some other incredibly common frameworks like logging.

dot_NET_Junkie Sep 29, 2012 at 11:02 AM 
It's not very popular since this project is only useful for reusable frameworks. For line of business application (that's about 99% of all code written) this abstraction is useless. When you apply the Dependency Injection pattern correctly, there is no need let your LOB application take a dependency on the CSL abstraction.

AlHudson Sep 29, 2012 at 4:33 AM 
Awesome!!! and BTW very useful.. I don't understand why is not more popular.