6 ms·

Is upgrading every 3 years really that bad? As far as I know, they typically aren’t removing features or causing disruptive changes in .NET versions. They did

Is upgrading every 3 years really that bad? As far as I know, they typically aren’t removing features or causing disruptive changes in .NET versions. They did when switching away from .NET Framework, but this was because they had to reimplement many features from scratch to work on other platforms, and certain parts got left behind.

croes 1y ago
With all the dependencies that maybe getting an update to the new .Net version, yes.
ewoodrich 1y ago
The last few .NET updates have been pretty much effortless updates for us. These are internal web apps and not using really esoteric C# features but that probably describes a reasonably large percentage of enterprise .NET adoption.
- nartho 1y ago
  I don't think they introduced any breaking changes after .NET 6
  - Salgat 1y ago
    The only breaking change for us was how .NET 7 introduced [FromServices] which causes controller methods to use dependency injection for attributeless parameters. Confused me at first since it was a rather subtle update that didn't break anything until runtime.
  - orphea 1y ago
    Every version had breaking changes, they could not affect you too much though: https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...
starik36 1y ago
When I need to send someone an app, I usually use .NET Framework 4.8 because I know it's already installed on every recent version of Windows. This way all I have to distribute is a single very small exe. No need to package a framework with it. Similar feat with .NET core usually results in a 70-80MB executable.
- SirMaster 1y ago
  Is 70-80MB really a big deal to distribute in 2025? Also if you use trim unused code and compress the executable in my experience it's usually a lot smaller than this.
  - starik36 1y ago
    That's with trim. You still have to distribute the framework. That packs a punch regardless.
nic547 1y ago
.NET LTS is on a 2-year cycle, isn't it? I've worked in .NET shops with very niche WPF/WinForms applications where customers were years behind with our software/major .NET Framework releases. I don't think it's a technical challenge, more a cultural one.
- WorldMaker 1y ago
  A shift in those cultural dynamics is that you can ship the current .NET LTS with your app (or even STS if you feel like making that sort of security support SLA with your own clients). You aren't relying on their Windows Update habits (or lack of them) or having to install a big .NET installer that might break their other apps. They may still get left behind on an older version of your software because they want to be, but their relationship to Windows is no longer the big excuse/reason to skip updating to your latest that it used to be.
- brokencode 1y ago
  You are right that it’s on a 2 year cycle. Though there is support for 3 years, so you could safely put off an upgrade for up to a year if there are breaking changes one release.

croes 1y ago

With all the dependencies that maybe getting an update to the new .Net version, yes.

ewoodrich 1y ago

The last few .NET updates have been pretty much effortless updates for us. These are internal web apps and not using really esoteric C# features but that probably describes a reasonably large percentage of enterprise .NET adoption.

nartho 1y ago
I don't think they introduced any breaking changes after .NET 6
- Salgat 1y ago
  The only breaking change for us was how .NET 7 introduced [FromServices] which causes controller methods to use dependency injection for attributeless parameters. Confused me at first since it was a rather subtle update that didn't break anything until runtime.
- orphea 1y ago
  Every version had breaking changes, they could not affect you too much though: https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0 https://learn.microsoft.com/en-us/dotnet/core/compatibility/...

starik36 1y ago

When I need to send someone an app, I usually use .NET Framework 4.8 because I know it's already installed on every recent version of Windows. This way all I have to distribute is a single very small exe. No need to package a framework with it. Similar feat with .NET core usually results in a 70-80MB executable.

SirMaster 1y ago
Is 70-80MB really a big deal to distribute in 2025? Also if you use trim unused code and compress the executable in my experience it's usually a lot smaller than this.
- starik36 1y ago
  That's with trim. You still have to distribute the framework. That packs a punch regardless.

nic547 1y ago

.NET LTS is on a 2-year cycle, isn't it? I've worked in .NET shops with very niche WPF/WinForms applications where customers were years behind with our software/major .NET Framework releases. I don't think it's a technical challenge, more a cultural one.

WorldMaker 1y ago
A shift in those cultural dynamics is that you can ship the current .NET LTS with your app (or even STS if you feel like making that sort of security support SLA with your own clients). You aren't relying on their Windows Update habits (or lack of them) or having to install a big .NET installer that might break their other apps. They may still get left behind on an older version of your software because they want to be, but their relationship to Windows is no longer the big excuse/reason to skip updating to your latest that it used to be.
brokencode 1y ago
You are right that it’s on a 2 year cycle. Though there is support for 3 years, so you could safely put off an upgrade for up to a year if there are breaking changes one release.