Object-Oriented Principles and SOLID design are very important.  Along with those are the principles of Explicit, Transparent, Self-Documenting code.  It all sort of comes together nicely when done correctly.  Inversion of Control is obviously an important part of it.

Another important aspect is the idea of scope.  When an application is written correctly, the scope of an object is very clear.  You declare it, you initialize it, and if unmanaged resources are involved you dispose of it.

Don't IOC containers break a lot of these principles?  You define a bunch of dependencies and declare the relationships and scopes, and bing bang boom: you magically have some addon that alters your code or I.L. at some point and makes things work.  That isn't explicit or transparent.

Obviously there is no real magic, you can look under the covers and see how this gets accomplished.  But when you look, it isn't pretty.  We let that slide because it makes coding easier?  I agree that when I write or read code using IOC containers, it gets rid of some slightly inelegant code.  My code uses factories and builders and keeps them close to their objects so D.I. is simply and not "nested" at the topmost layer.

IOC Containers allow access to private members.  And how do "Lazy" injections work?  If I were to manually write my code to make it get away with the things IOC Containers get away with, I'd be flamed to death for horribly unsafe and not-SOLID code.

A programmer brought me a class with a dozen dependencies very elegantly injected with a pre-defined scope and relationship.  The writer of that class says, "If we didn't use an IOC Container, the Constructor would have a dozen parameters!!! That's horrible!"

Well yeah, it is horrible.  It then tells you that you're not programming correctly and are probably breaking S.R.P.

I think IOC containers were a great idea originally when their main purpose was to get rid of duplicate interface code for D.I. factories/builders.  But it has come too far and now performs too much magic under the covers.

So the question isn't about whether or not a developer wants to learn how to interpret the magic of IOC Containers.  IOC Containers are not a new design pattern or technology as many say.  IOC Containers are addons that alter your code to allow it to do things it wouldn't be able to using SOLID design.

In case the question isn't clear:  Don't IOC containers both break, and allow coders to break, a lot of OOP/SOLID principles?  It is naturally not explicit or transparent, it alters your code at some point to a non-encapsulated static mess.  It tries to control the scope of an object outside of normal practices.  Let me know if I'm missing something.