Nothing major, just the typical wrong implementation getting used for 'x' interface under 'y' context. I.e. we have multiple implementers of a given interface, and IoC not knowing which to use, or worse using the wrong one.
Overall it just didn't make things any easier. Didn't make them significantly any more difficult I must add though.
I can certainly see that in the case where you have multiple implementers of a single interface it can be a pain.
Generally that's the sort of stuff I'd shy away from using an IoC container for anyway.
Where I find it really pays dividends is in the general infrastructure type stuff.
My day to day work is using WPF, where you might have a viewmodel that is bound to a view.
That viewmodel will likely have several dependencies of things like UI & infrastructure services, possibly other viewmodels.
Those things in turn may have other dependencies themselves.
If you need to introduce another dependency to a viewmodel, you just put it in the constructor and let the container handle things for you if you have one.
Otherwise you'd need to change things wherever you create that class. Even if you have a factory to sort it all out and ensure it's all done in one place, you still need to potentially deal with chains of dependencies that are being passed in.
Obviously it's not great practice to have everything with dependencies to everything else, but it's certainly the case where most things aren't quite as simple as just adding in an extra object to the constructor.
Additionally, things like the auto mocking framework I linked above provide lots of benefits.
When creating tests you simply resolve the object through the auto mocker and it creates any dependencies as proxy objects.
Any of them you need to mock a particular method call, you can just get that proxy and mock out the method.
