5 ms·

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.

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.
  - 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.
        mattmanser 2y ago
        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.
      - croes 2y ago
        Nothing bad on staying a still supported framework. Most of the time boring old technology beats shiny new one.
  - atmavatar 2y ago
    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.
- sebazzz 2y ago
  .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.
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.

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.
- 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.
      - mattmanser 2y ago
        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.
    - croes 2y ago
      Nothing bad on staying a still supported framework. Most of the time boring old technology beats shiny new one.
- atmavatar 2y ago
  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.
sebazzz 2y ago
.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.

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.