Hacker News Reader

Comment by eterm | Hacker News Reader

Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.

And the support lifecycle for .NET4.8 is ironically better than they are for .NET 6 (already dead) and .NET 8, because of the shipping-with-windows thing.

The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.

So yeah, there'll be a bunch of .net framework code around for a while.

That said, it's frustrating, because in some places the performance just isn't there, and there are so many nuanced differences between them there's a weird effect trying to switch between them.

You not only have to recall which APIs are available in each, but the performance differences between otherwise identical (or near identical) APIs.

View on HN

> Porting .NET framework to .NET core / standard / 6+ really isn't as smooth as MS would like you to believe.

Having just spend the better part of 3 months porting a lot of legacy projects, you're absolutely right, but I am not sure where MS said this would be smooth. There are some processes that are standard enough but certainly there is a lot of hands on work involved, and actually for good reason, there are performance and security issues that need to be addressed (In my brief, and hopefully final experience).

That said, porting from event .net versions (stable LTS versions) such as 6 -> 8 has so far been flawless, I think over the last year, we ran into maybe some minor semantic issues.

It's not perfect, but I have to defend MS unfortunately, they are taking things in the right direction while being tied to a LOT of legacy enterprise clients and systems.

I have pretty much the same experience, but it is highly dependent on what you were using.

- WCF ? (very enterprisy i know) : you are still mostly screwed

- aspx ? compulsory rewrite

- MVC ? mostly smooth (but most of the pain is in initialization so comes early and can discourage newbies)

- Console ? mostly smooth

- before .Net 6 ? it was a death march, not only many API were lacking, but third party libraries were also missing.

- .Net 6 -> .Net 8 ? very smooth

I'd add that WPF was "don't bother" up until recently when WPF support was added. (Though I don't know if that means stock WPF or that it supports the breadth of WPF controls out there, and whether it requires WPF component vendors to make changes)

We just migrated our massive WPF application to .NET 8 and there are a handful of libraries that are not supported or had to be replaced but overall it was surprisingly smooth. The biggest issue we have is that garbage collection seems to have taken a huge hit and there are bugs in the Microsoft WPF components (any sort of list view in particular) but it's all relatively easy to work around.

There is WCF Core but it is not even close to feature parity with the 4.8 WCF.

Yes, it's partial parity, and is server only. It's also not easy to migrate; the upgrade-assistant tool typically just gives up.

The client libraries only came separately, and much later[1] , and in typical "Fuck your migration path" fashion, doesn't have any .NET standard support.

[1]: ( https://devblogs.microsoft.com/dotnet/wcf-client-60-has-been... )

After.NET 6 upgrading is mostly just changing the number in the project file.

Support for .NET Frameworks 4.8 is essentially forever and .NET Core requires you to jump one version up almost every year, which has a much higher maintenance cost.

> .NET Core requires you to jump one version up almost every year,

Close.

* The requirement is to jump every second year when a LTS version comes out. Last one was .NET 6 to .NET 8. And next, .NET 10 will come in November 2025. You can jump 1 version every year, but it's not a "requirement".

* It's just called ".NET" now, not ".NET Core". There is no ambiguity in e.g. ".NET 8" - it's the modern version formerly known as ".NET Core".

* Release is every year in November, and every second one is LTS. there's no "almost", it's every time. IDK if this will still be so in 10 years time, but it's been consistent.

* maintenance cost? Yes, you have to review project files and build pipelines in order to to update, so there's some detailed work, but the actual breaking changes and puzzling issues are few to non-existent. It typically goes very smoothly after you change some numbers.

We've only done it once so far, who knows if it'll stay that smooth. Before that it was chaotic, to say the least.

This is completely false and goes against the experience of the vast majority of the teams.

Using .NET Framework carries significant risk and opportunity cost. Updating LTS every 2 years usually comes with simply bumping up versions and rebuilding.

Yep, this is correct. Not to mention the maintenance cost of .NET Framework going up every year because the library ecosystem moves onwards, eventually, from legacy behaviors.

And also, bumping the .NET version from 8 to 9 or 9 to 10 is typically a very small effort for most. I think what the OP is describing is working for a software cost center where they don't value the software system itself.

Avoid odd numbers for production. Update/upgrade every two years.

.NET Framework just get security updates means no rebuild, no unnecessary updates for your users

But you will only be able to hire the employees willing to tolerate working with it. Especially the condition of not planning any form of modernization.

And as phillipcarter noted, increasingly more libraries drop 'netstandard2.0' target, depending on the workload the performance difference is going to be anything between 50% and multiple orders of magnitude (e.g. Regex engine has gotten tens of thousands of percents faster for some patterns).

Working with .NET Framework from non-Windows environment requires using Parallels / UTM on macOS or QEMU or any other VM env. on Linux - there's Mono but it's not a replacement, and I don't think Visual Studio will work under Wine.

There are all sorts of hidden costs that you don't plan for, that come with using .NET Framework.

Honestly, if a project in 2025 is on .NET Framework, I am simply not going to believe any statements about pending modernisation. Simply because if it was going to happen, it would have happened already.

Not sure why this is so aggressively downvoted. I work in legacy software and it's true. A firm that's still on .NET Framework, PHP 5.6, or Java 8 is likely to stay on those versions for the near future.

We just moved from 4.6.1 to 4.8 this year. We maintain a frontend(++) for a major enterprise software package, and follow them. They just moved to 4.8 so we did as well. Not even the point release. The contractor I work for is pretty conservative, he likes his 1+ million dollar home and worldwide vacations. He won't be changing anything without being forced by Microsoft.

Even if Microsoft puts in a huge effort to updating a migration tool to be seamless, we wouldn't use it. It'll only happen when either the larger enterprise corporation migrates, or when Microsoft forces people off 4.8.

Writing C# code in modern .net is so much better.

It's close to the change when get/settwrs were made mostly redunant (but not quite).

Just so much less boiler plate that you didn't even really realize you were writing.

Nothing bad on staying a still supported framework.

Most of the time boring old technology beats shiny new one.

One of the bigger problems with staying on .NET Framework is that it limits you to C# 7.3, which lacks a lot of new language features (e.g., most pattern matching, records, nullable reference types, etc.). It can be both frustrating and even potentially career limiting to be stuck on that for too long.

You can use newer LangVersions with older targets, including .NET Framework. A good deal of features can be made work by just setting LangVersion: 13 and doing dotnet add package PolySharp. But of course this won't bring missing span-based APIs, new ASP.NET Core and EF Core, etc.

However, the workplaces that adamantly refuse to upgrade also select for developers who may not be familiar with pattern matching or other features at all, and never read release notes.

.NET as well. If you do a framework-dependent deployment, then in many cases you only need to run Windows Update, just like with .NET framework.

Yes... if you do self-contained deployments or build containers, then of course you're tied to the version you've built with - but that is your choice and therefore your responsibility.

You are now blaming having that some deployment choices cannot be updated manually. It is the wrong mindset.

It’s not “completely “ false. Otherwise this sentiment wouldn’t exist and .NET 4 would be a nice memory like Windows 2000.

Opportunity cost? Sure, but you can’t deny that small teams that just wanted some stuff to please a business itch were able put the shitty code in whatever Win server they had at the time and forget about it. They didn’t have to ask IT to evaluate any installs, it was right there. And today in win 10 servers, that code still runs, returning ugly aspx.

We have some equivalent 2.1 stuff laying around and no one wants to go through the trouble of updating that.

You’re probably going to say something like “well that’s what you get when you just let your code rot and no one cared to document it and maintain it”. Yes, true, but that’s not the on topic point, one of those constantly comes up in vulnerability reports and one doesn’t.

> .NET Core requires you to jump one version up almost every year, which has a much higher maintenance cost.

This is basically seamless now, the framework isn't changing in backwards-incompatible ways anymore.

For what it's worth, migrating from Java 8 to 11 is much smoother than .Net 4.x to .NET Core / Standard / 6+. In all honesty, in all the project we've migrated it was only ever so slightly more painful than migrating 11->17 or 17->21. You typically have to upgrade some libraries and your version of Gradle (assuming you're using it).

There is a much stronger case for enterprise apps being stuck on .NET 4.x.

In my experience porting from .NET Framework to .NET Core isn't that difficult per se -- it is the frameworks that we are stuck on that cause the difficulty, namely if you have a large project using ASP.NET pages and EntityFramework classic, which do not have compatible .net core versions really. The .net core replacements are objectively better, but have significant conceptual and API differences that prevent a simple move.

There are some community projects that try to fill this void by porting entityframework classic to .net core for example though.

EF6 works fine on .NET Core. EF Core does not work on .NET Framework.

> The odd-numbered .NET releases aren't even worth looking at from an enterprise perspective.

Not hard to argue the opposite either; as you have to upgrade every 2ish years anyway is the LTS track really that valuable compared to updating every march-ish when the latest has been proven? 6 -> 7 -> 8 -> 9 was trivial too.

Meanwhile a friend of mine still has 4.6 going strong and I’d struggle to argue a reason to migrate.

Reply on news.ycombinator.com