I suspect Microsoft wants most developers to throw their hands up and just follow the "hook your app up to our $$$ azure authentication products $$$" tutorial.
The happy path for AspNetCore could be achieved if Microsoft started the entire conversation with "Here's a request pipeline and here's how you add middleware to it". Everything else is some form of abstraction on top of that. You can learn about how to do all of this 1 afternoon if you know what to focus on.
Once you figure out how to get at HttpContext with your services available in that scope, you have the rabbit entirely cornered. Relying on Micrsoft's middleware to do everything for you is how you get trapped in their puzzle box for all eternity.
It has a excellent server (kestrel), a middleware pipeline, routing system and common dispatching patterns like pages, MVC or minimal apis.
It is excellent in every degree of abstraction. Love the basics, go for kestrel. Work with http basics go for middlewares. Want to work with request and response principles and routes go for minimal API. MVC for a bit more structure. Pages for a traditional set. And Blazor Serverside if you love state.
All of this experiences are good.
I would prefer some examples what is bad here! And spare me DI.
To be clear I have .Net experience going back to the beta frameworks in the early 2000’s and have hand held some huge products on the platform from inception to maintenance phase architecturally and infrastructure wise. It’s been a bloody rough ride and I regret every moment of it and wish I’d picked another platform bet. I’ve had the entire stack rug pulled from underneath major projects multiple times and burned months in pointless rewrites due to tech changes and obsolescence. The majority of the open source ecosystem is broken or abandonware and the commercial bits are overpriced, with poor support and barely work. It’s hell.
The only good bit has been being paid by the hour to unfuck stuff which has been profitable.
But that doesn’t give me much confidence when it comes to finding out how to fix things that go wrong.
The Microsoft documentation is garbage, the worst I have seen. But the language and framework are good.
The c# language is now like an Indian train at rush hour. Busy and dangerous. Very easy to shoot yourself in the foot if you don’t know what you’re doing. LINQ and its contract breaking promises are a fun one for example. One interface returning IEnumerable<T> and you’re in big trouble when someone assumes the data is already materialised.
If you are referring to lazy loading, awaiting calls and ToList()..ing them solves that too.
I know I will get crucified for this, but that's what happens in practice.
We're talking a lot about doing something for the environment, it could start with using "fast enough" languages.
Of course we need to find a compromise between performances and ease of use. So I wouldn't abandon .net core for Ruby or Python, but I would for something as performant (or better ofc) but friendlier to use.
Easy to make a simple endpoint for a tutorial, but after building any serious application the other language stacks end up hooking together several large packages and modules just to get the same standard functionality that ASP.NET provides.