5 ms·

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

by eterm 2y ago

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.

a1o 2y ago
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.
- SideburnsOfDoom 2y ago
  > .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.
  - mattmanser 2y ago
    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.
- neonsunset 2y ago
  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.
  - phillipcarter 2y ago
    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.
    - jrs235 1y ago
      Avoid odd numbers for production. Update/upgrade every two years.
  - croes 2y ago
    .NET Framework just get security updates means no rebuild, no unnecessary updates for your users
    - neonsunset 2y ago
      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.
- naasking 2y ago
  > .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.
bilekas 2y ago
> 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.
- folbec 2y ago
  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
  - smileybarry 2y ago
    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)
    - theryan 2y ago
      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.
adzm 2y ago
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.
- eppsilon 2y ago
  EF6 works fine on .NET Core. EF Core does not work on .NET Framework.
unscaled 2y ago
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.
DimmieMan 1y ago
> 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.

by eterm 2y ago

a1o 2y ago

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.

SideburnsOfDoom 2y ago
> .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.
- mattmanser 2y ago
  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.
neonsunset 2y ago
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.
- phillipcarter 2y ago
  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.
  - jrs235 1y ago
    Avoid odd numbers for production. Update/upgrade every two years.
- croes 2y ago
  .NET Framework just get security updates means no rebuild, no unnecessary updates for your users
  - neonsunset 2y ago
    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.
naasking 2y ago
> .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.

bilekas 2y ago

> 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.

folbec 2y ago
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
- smileybarry 2y ago
  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)
  - theryan 2y ago
    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.

adzm 2y ago

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.

eppsilon 2y ago
EF6 works fine on .NET Core. EF Core does not work on .NET Framework.

unscaled 2y ago

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.

DimmieMan 1y ago

> 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.