Also, .NET 5 is now here, and 6 is already in preview, which are much, much more backwards compatible than .NET Core 3. And unlike Python, we had .NET Standard to start migrating code between Framework and Core. A lot of extant code on NuGet has already migrated and there is really very little you can't do these days.

Unless one is using third party controls, CMS like SiteCore, SharePoint and Dynamics, writing custom .NET code to be called by SQL Server stored procedures, having a working WCF infrastructure, using RDMS with EF 6 that isn't SQL Server, in-house stuff that isn't fully covered by the Windows Compatibility Pack, and a couple of other little things.

Also asp.net webforms is not supported, webservice/soap are 'supported' but the tooling is broken and i don't think you could extend a system with it in modern VS. The winforms editor works but is buggier with each new version, and asp.net mvc projects are similar but changed, and I'm sure the list of issues continues.

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.

So keep using .NET Framework. v4.8 is only 3 years old and there is no end date set on the support yet. Considering the last version of the v3 era will be supported until 2029, I'm sure the last version of the v4 era will get quite a long period of support as well.

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.

On my world those decisions come with project budget, if no department puts the money to hire the consultants that would do the job, there is no transition.

What do you want me to say? Because your organization is stuck in the past, that means .NET can't move forward?

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.

It is not me that is asking, rather the Fortune 500 companies where software development is a cost center, that hire us to keep their production systems and factory lines rolling.

On my pet projects I use whatever I feel like.

Not even Microsoft teams themselves have done it, plenty of MS stuff like SharePoint, Dynamics and SQL Server rely on .NET Framework.

Source being compatible doesn't help when the libraries require code rewrites anyway.

SQL Server itself does not rely on .NET Framework. SQL CLR, an optional component does. We run SQL Server in Linux containers now.

MS SQL Server started out as a port (to OS/2!) of Sybase SQL Server, which ran on Xenix (among other unixes). History doesn't repeat, but it does rhyme.

Try to run SQL Server stored procedures that rely on SQL CLR.

Why? That's just asking for poor perf, even on Windows. I would never do that.

Leave CLR in applications, where it belongs.

Customers decide what gets done.

Actually its not that easy, depending which parts of framework you used.

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.