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


enorl76 Oct 23 at 2:34 PM 
Of note to @dot_NET_Junkie, there's a System.Common.Logging open source project designed to address this. I'd like the Framework guys to actually begin to pull THESE types of frameworks into the core frameworks, so that EVERYBODY is able to reference the INTERFACES and not actual implementations (of Logging/Dependency injectors/etc)

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.