Comment by stereopixels | Hacker News Reader

Comment by stereopixels | Hacker News Reader

I'm a .NET developer, and honestly, this is the worst part of being one; we get good third party tools, we get promises from Microsoft about them being all about open source, and Microsoft constantly move in and obliterate all the competition; there are countless examples out there. A few years ago we had a great amount of choice around DI containers for example - they filled an obvious gap Microsoft had given no solution at all for within their framework despite its many years of existence. Then one day they come along with a DI container that is far inferior to the existing offerings, but it's the default on a new project... the whole community immediately stays with this default option despite the obvious inferiority. Today I never find any modern .NET apps using anything other than this default, and I still think it's inferior to what we had.

Microsoft have always adhered to 'Embrace. Extend. Extinguish', and it is alive and kicking today in every area of open source they touch, be it this, GitHub, Windows Subsystem on Linux... they have no real interest in open source, except to crush it as best they can.

> 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.

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

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.

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.

I don't think EEE applies to killing off unmaintained, underused and extremely badly written DI containers like Unity DI or Autofac. Honestly, both can burn in hell. And nowadays M.E.DI isn't the sole choice and there is a rich set of alive and well DI frameworks to use depending on your needs.

I used to do a lot of .NET. That’s the community’s fault, not MS.

Reply on news.ycombinator.com