[littlecranky67]

> one day they come along with a DI container that is far inferior to the existing offerings

Microsoft baked-in DI is purposefully designed to be as minimal as possible, such that you can start quickly without getting into too much abstractions. And once you reach a level where you need a more powerful (and thus complex) DI container, you can easily plug it in and seamingly bridge within the minimal MS one. This allows to migrate in iterations to your DI container. And from my experience, the built-in one is enough for a lot of basic usecases.

Plus, it is way easier to move a codebase from MS-built in DI to any other 3rd party DI, than to move a codebase which grew without DI at all.

There is a reason why there is a ton of DI containers out there (Autofac, Funq, NInject, CastleWindsor, StructureMap etc) and ALL are differently opinionated and made different design decisions. What would have been your suggestion for MS, which one to bake into the ASP.NET Framework? There is NO way you pick any and not upset the people on the other side of the fence. IMHO MS did the right way, and tried to go with a minimal version that shares a common denominator with all of them, so they can be easily plugged in when needed. This is exactly what having choice means.

[styx31]

Perfect anwser. I have used DI for years, and the common DI abstraction is a great features: it allows people to start using DI and allow MS to use it internally, then, if you find it too limited or like some custom features, then start using a custom one, which is a breeze.

[kennethh]

What would you recommend as an easy upgrade from the default DI?

[littlecranky67]

What do you mean? If you need an upgrade from the default DI, then YOU should ask yourself why do you think you need it, gather requirements, identify what is missing from the existing solution, and chose one of the many DI container based on your needs and findings. And most of those containers can be used with MS existing DI pipelines.