See http://www.geurtsrus.com/gerke/2005/03/ioc-in-net.html:
Before writing a new framework it might be worthwhile to have a look at existing .NET efforts (http://csharp-source.net/open-source/containers). A thread on TheServerSide.net tackles the subject as well (http://www.theserverside.net/news/thread.tss?thread_id=27409).

Hi Gerke,

You're right about looking at the alternatives in this field first. And I did. I think my view on IoC is much like the others (Sping.net, Pico, Castle) though there are some subtile differences..

Maybe just my lack of insight, maybe i'm after something else then other IoC framework, maybe theirs works better for them & mine better for me, i'm dying to find out :).

An example would be querying service instances: In most containers this is done by specifying a string literal. If you map Containers to SOA (no, not webservices, soa) this string literal would function as the contract between service & consumer. In my opion (a modest one) containers are better off using a 'real contract', practically a type's interface definition to query services. As done in the ComponentModel.

P.S. I'm not a colleague, I work at Macaw (www.macaw.nl)

If you'd like, in the config options in your admin section, you can set "Olaf Conijn" to "Olaf Conijn [Macaw]". That's how more people on blogs show who they're working for ! :)

Problem with .Text is that it copies the text inside the name itself into every post, instead of setting a reference and getting the name with an inner join.

IoC in .NET