Absolutely this. They changed names, project format, build tooling, etc faster than the ecosystem could keep up. You couldn’t even be sure there existed a set of compatible ASP.NET Core, EF, and standard library packages in nuget without endless trial, error, and binding redirects.

I tried 2-3 times up to and including .NET Standard 2.0 to switch and got burned by busted tooling and package conflicts every time. I’m starting a new project now and am still wary.

Nuget conflicts is still a big issue IMO.

One of the major pains of my life as a .NET dev who does .NET core right now is Nuget and binding redirects!

Oh yea, absolutely. I've become weary of trying new Microsoft stuff. One example I had recently is with their Bot framework. They came out with a shiny new template earlier this year, they called it the Enterprise Bot Template. Since we were gonna build a bot, we decided to use this, because it was a nice template with all the best practices and lots of features included. Now that we are finished with the bot, I tried to look up the documentation that explains how to deploy it. Guess what? Documentation is _deleted_. Completely gone. Turns out they have already discontinued the template and have yet _another_ template in place, that's only been around for a few months. Of course many things are/work differently, so migrating is a pain. And there is no good migration guide. They basically just say "create a new project with the new template and make all your code changes there". It's infuriating... At least keep the old documentation only, don't just delete it.

Tip: A good part of microsoft documentation is now hosted on github... you may want to have a look at the revision history there and try to find the deleted docs this way (for example this is the repository for azure bot: https://github.com/MicrosoftDocs/bot-docs/tree/live/articles ).

If you stick to the LTS releases, especially v2.0 and above, everything is very solid. It always best to wait for version 2 anyway with MS projects.

That doesn't solve the problem of porting code that has dependencies on libraries that only work with .NET Framework, and will die the day .NET Framework 4.8 reaches EOL.