What should I consider when choosing a dependency injection framework for .NET

Question

see also Which C#/.NET Dependency Injection frameworks are worth looking into?

There are now many dependency injection frameworks to choose from. You used to often be forced to use a given dependency injection framework due to a library you were using. However the Common Service Locator library has enabled library code to be independent of injection frameworks.

The time it takes to learn all of them well enough to decide which to use is unreasonable. I don’t believe that we have yet reached a stage that we can talk about the best dependency injection framework. So what questions should I be asking about the project and myself to help decide on the best dependency injection framework to use in a given case?

It would also be useful to know why you choose the dependency injection framework you are currently using and if you are still happy with that choose.

Is there yet a useful vocabulary to use when comparing the styles of dependency injection frameworks?

Does the Service Locator library work in real life, or are you skill forced to use lots of different dependency injection frameworks in the same project?

How easy is to refractor you code with each Dependency Injection Framework, e.g do tools like ReSharper work well with a given framework?

Answer 1

FYI, just this morning I came across an interesting comparison between all the .NET IoC containers here:

http://elegantcode.com/2009/01/07/ioc-libraries-compared/

A handful of questions:

1. How much mainstream support do you need? Spring is probably the biggest one out there. Everyone has used it or has heard of it by now, so lots of info. It also probably has the largest number of features, but that means there's just more to learn. A smaller container like Autofac might be nice, but you might come across an issue you won't find help on.
2. Are you handy with XML configuration? Every IoC container relies on configuration and setup of some sort. Spring and Unity are XML heavy.
3. Is this a permanent choice? If you are at one of those places where you only get one shot at a choice, it won't matter. But, if you ever want to choose another solution down the road, you probably don't want an IoC that requires you to attribute your classes (sorta the inverse of the above question) because you'll hate yourself when you have to rip all that stuff out. In comparison, wrapping out some XML config might not be as painful.
4. What's your shop like? I had trouble pitching a couple of open source options just because of the "gasp! it's not Microsoft!" reactions. If you're a straight MS shop, using Unity will be a much easier cultural win.

On a personal note:

I've used StructureMap for the same reasons mentioned in the blog I linked. I think XML config is a giant pain to maintain and, especially, debug (see WCF). I haven't tried Ninject yet, but based on their marketing, it must be super rad!