- More support for UNIX and mainframe flavours
- Given the multiple implementations, there are plenty of GC, JIT and tuning options to chose from
- .NET Core is the Python 3 of .NET world, not everything from .NET Framework is available or portable to non-Windows platforms
- Several JIT optimizations quite common in JVM world are only now coming to CLR, like dynamic rewrite of native code
Source being compatible doesn't help when the libraries require code rewrites anyway.
Leave CLR in applications, where it belongs.
Also from my experience coaching and consulting there's a significant learning curve for .NET framework developers to work in the new core/.NET 5 systems.
https://docs.microsoft.com/en-us/lifecycle/products/microsof...
I bit the bullet and transitioned from WebForms to ASP.NET Core. I think it's easier than WebForms ever was. You can replicate 90% of what WebForms did with Razor Pages, but you also get much easier support for building RESTful APIs. And with DI built-in, I don't have to worry about junior devs forgetting to close/dispose database connections ever again.
If you've followed the .NET blogs at all, they have very good reasons they haven't prioritized support for these legacy systems. There isn't some cabal of platform designers in Redmond scheming on how to screw over developers at ossified orgs.
Not sure why I'm bothering. Everytime someone mentions .NET on here, someone comes out of the woodwork to complain about their pet features not being supported. Actually, come to think of it, it's often you in particular. We're going from .NET Framework being fundamentally tied to Windows to a new .NET that runs on everything. ASP.NET was built on HTTP.sys, a Windows driver for a web server. I don't know, is it terribly surprising that trying to migrate .NET off of Windows-only dependencies is going to break things downstream?
But if you still need this stuff that only runs on Windows, well, you got at least decade of support to look forward to.
I literally think you're asking for too much.
On my pet projects I use whatever I feel like.
It's certainly reasonable, but will take re-work for many applications beyond the project structure migration. I think in .NET 6/7/8 the .NET framework migration situation will improve to be mostly pure migration.
For example I migrated about 75% of a moderately large winforms system directly, but 25% needed rewrites due to missing core implementations for framework libraries. e.g. MS chart component not implemented in core yet, soap services changing to grpc, and various others. And this system was originally built to minimise third party dependencies and use the core framework or microsoft provided libraries wherever possible.
Is there anything in .NET 5 you're missing from .net 4.x?
MS is a big company, they aren't going to immediately migrate everything just like Google didn't migrate every single project to Go when they were heading it.