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 9:03 AM by gblock, version 4

Comments

SEWilson Jan 29 at 5:25 AM 
@Bouldraak's comment is spot on, however, I would note that CSL makes it's possible to use DI containers whether or not the dependencies being placed in the container are DI aware, thus, there is no need to rely on coding conventions as @junglemole notes "is first and foremost good design by itself". While it may be true that adopting DI coding conventions on every codebase is a good design decision, what we've seen over the last 30 years are systems which rarely make "good design first and foremost". Quite the contrary, we often see tightly coupled components that don't support composition, DI nor IoC but instead behave more like monolithic systems which only ever exist in a single configuration.

junglemole Dec 15, 2015 at 9:43 AM 
that's nowhere near a problem to design your system in a way it don't give a rubber duck about what IoC container you choose.

your excuse is very weak and unconvincing. you are just resort to strawman here.

dependency injection is not a container, but a pattern. containers just implement it. and if you code is DI-ready (which is first and foremost good design by itself), you can use any IoC container without further investment in your own code.

enorl76 Oct 23, 2015 at 1: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 7: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 5: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 10: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 3:33 AM 
Awesome!!! and BTW very useful.. I don't understand why is not more popular.