4 ms·

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

by 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 2y 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.
    - SideburnsOfDoom 2y ago
      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.
      - Capricorn2481 2y ago
        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.
        BuckRogers 2y ago
        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.
- culopatin 2y ago
  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.
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.

by 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 2y 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.
  - SideburnsOfDoom 2y ago
    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.
    - Capricorn2481 2y ago
      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.
      - BuckRogers 2y ago
        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.
culopatin 2y ago
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.

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.