Constructor DI is extremely important though, because time and time again lazily injected dependencies via properties results in circular dependencies and sometimes missing dependencies that fail at runtime. I'm not talking about simple cycles either, every time I have seen lazy dependency injection done has ended up in an A -> B -> C -> D -> A scenario.

Passing required dependencies by constructors makes this extremely apparent, not just to the DI framework but to the developers themselves. With constructor injection I can immediately grasp exactly what dependencies an object depends on without even going into the full code flow to look at all the code to find all the IOC container calls.

Edit: Also constructor injection is critical for testing dependency injection. IT allows you to have automated tests that construct every relevant object using the same DI setup as your live application and you can verify that the DI framework can resolve dependencies for everything.

If your DI is lazily done this cannot happen unless you explicitly call all code flows, opening yourself up to runtime errors that may be missed. Unit tests won't catch this because the dependencies of your production site will be different than the dependencies of your test scenarios.