I'm a .NET developer with 5 years of experience, mostly in the enterprise space. I've worked on large projects with .NET 3.5 - 4.7, and recently I've been building things in .NET core.

Honestly, .NET core makes a lot of sense for new projects that need to be highly scalable. If you have an API service that's hosted in a cloud provider, or a tool that generates PDFs of items, or a tool that scrapes API data and chucks it in a database, then this is great. These are simple applications that do not need an awful lot of authentication, crazy UI frameworks, or other windows-only features.

The code itself runs faster [1]. It might not matter for business / CRUD applications, but that's a nice to have thing.

The biggest selling point is cross platform support. Now, I don't care if the company switches from Windows 2016 VM's to some variation of RHEL. My code will work on that too. This gives your organization improved flexibility and reduced technical debt.

If you have a big legacy application using .NET Framework, it's probably not worth rewriting it for .NET Core. You will run into package conflicts. I have had to rewrite ".NET Framework only" pacakges to support .NET Core. That will throw your estimates off and probably delay the project. And that becomes really difficult to justify to project stakeholders.

[1]: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

As someone that has been on and off .NET since the pre-release days (thanks to working at a MSFT partner back in the day), the constant reboots from the last couple of years, and breaking changes across .NET Framework and .NET Core (e.g. WCF, EF 6 tooling), inspire a wait-and-see attitude among a large majority of us.

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.

> My personal opinion is that Microsoft's absolutely terrible naming scheme fails to sell anyone on why it's different or important.

This is why it is very interesting that the next "Core" release is to be called ".NET 5". No more "Framework", no more "Core". Simple version math applies: .NET 5 > .NET Framework v4.6.8 && .NET 5 > .NET Core 3.0. Maybe it will be less confusion all around, hopefully, soon.

.Net Core is the future: It is clearly the .Net runtime environment Microsoft are putting their weight behind to eventually make it the standard.

Besides this future perspective, the real benefit from it you have today is that your project will (unless it uses Windows APIs, which is unfortunately way too common) instantly run on Linux.