5 ms·

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU.

When was the last time you actually used. NET? Because that's absolutely not how it is. The. NET runtime is shipped by default with Windows and updated via WU. Let alone that you're talking about .NET Framework which has been outdated for years.

torginus 7mo ago
.NET Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.
croes 7mo ago
.NET versions are faster outdated then .Net Framework 4.8
- stackskipton 7mo ago
  Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
  - tgtweak 7mo ago
    You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
    - stackskipton 7mo ago
      We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
    - rblatz 7mo ago
      Just ship a self contained build?
      - tgtweak 7mo ago
        This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.
  - croes 7mo ago
    A .net framework 4.8 app has zero hours of work. Why is it ok that you have to invest 2 times number of apps hours just because MS has such a short life cycle for its .NET versions.
p_ing 7mo ago
.NET runtime is not shipped with Windows, but once installed can be updated by WU. Only the latest .NET Framework 4.8 is shipped with Windows at this point.
tgtweak 7mo ago
The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.
- p_ing 7mo ago
  https://github.com/dotnet/core/blob/main/release-notes/10.0/supported-os.md#windows https://github.com/dotnet/core/blob/main/release-notes/10.0/... .NET 10 supports a Windows 10 build from 10 years ago.
  - tgtweak 7mo ago
    Yes and in the wild believe it or not you'll find windows 7 and windows 8. We had just deprecated support for XP in 2020 - this was for a relatively large app publisher ~10M daily active users on windows. The installer was a c++ stub which checked the system's installed .NET versions and manually wrote the app.config before starting the .net wrapper (or tried to install portable .NET framework installer if it wasn't found at all). The app supported .NET 3.5* (2.0 base) and 4 originally, and the issue was there was a ".NET Framework Client Profile" install on as surprising amount of windows PCs out there, and that version was incompatible with the app. If you just have a naked .NET exe, when you launch it (without an app.config in the current folder) the CLR will decide which version to run your app in - usually the "highest" version if several are detected... which in this case would start the app in the lightweight version and error out. Also, in the app.config file you can't tell it to avoid certain versions you basically just say "use 4 then 2" and you're up to the mercy of the CLR to decide which environment it starts you in. This obviated overrides in a static/native c++ stub that did some more intelligent verifications first before creating a tailored app.config and starting the .net app.
    - p_ing 7mo ago
      Hey I have a PC running 98SE ;-) I feel for those who have to support an OS no longer supported by the vendor. That's a tough position to be in, not only if a customer comes across a bug that is due to the OS, but it keeps you from advancing your desktop application forward.

torginus 7mo ago

.NET Framework is a Windows system component, but it's been deprecated and Microsoft is moving away from it. The modern .NET ships as either a downloadable runtime/SDK, or can be bundled with your application, meaning your app has no dependencies.

croes 7mo ago

.NET versions are faster outdated then .Net Framework 4.8

stackskipton 7mo ago
Point? I’m SRE on .Net project, we have been through 6-8-10 and its cost us about 2ish hours of work each time. As long as you don’t get crazy, .Net upgrades is just matter of new SDK and runtime and away you go.
- tgtweak 7mo ago
  You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
  - stackskipton 7mo ago
    We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
  - rblatz 7mo ago
    Just ship a self contained build?
    - tgtweak 7mo ago
      This was a sidecar application distributed by literally millions of installs per day - so having a 25MB "self contained" build was out of the question - we were targeting KB-sized distributables not 10's of MB.
- croes 7mo ago
  A .net framework 4.8 app has zero hours of work. Why is it ok that you have to invest 2 times number of apps hours just because MS has such a short life cycle for its .NET versions.

p_ing 7mo ago

.NET runtime is not shipped with Windows, but once installed can be updated by WU. Only the latest .NET Framework 4.8 is shipped with Windows at this point.

tgtweak 7mo ago

The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.

p_ing 7mo ago
https://github.com/dotnet/core/blob/main/release-notes/10.0/supported-os.md#windows https://github.com/dotnet/core/blob/main/release-notes/10.0/... .NET 10 supports a Windows 10 build from 10 years ago.
- tgtweak 7mo ago
  Yes and in the wild believe it or not you'll find windows 7 and windows 8. We had just deprecated support for XP in 2020 - this was for a relatively large app publisher ~10M daily active users on windows. The installer was a c++ stub which checked the system's installed .NET versions and manually wrote the app.config before starting the .net wrapper (or tried to install portable .NET framework installer if it wasn't found at all). The app supported .NET 3.5* (2.0 base) and 4 originally, and the issue was there was a ".NET Framework Client Profile" install on as surprising amount of windows PCs out there, and that version was incompatible with the app. If you just have a naked .NET exe, when you launch it (without an app.config in the current folder) the CLR will decide which version to run your app in - usually the "highest" version if several are detected... which in this case would start the app in the lightweight version and error out. Also, in the app.config file you can't tell it to avoid certain versions you basically just say "use 4 then 2" and you're up to the mercy of the CLR to decide which environment it starts you in. This obviated overrides in a static/native c++ stub that did some more intelligent verifications first before creating a tailored app.config and starting the .net app.
  - p_ing 7mo ago
    Hey I have a PC running 98SE ;-) I feel for those who have to support an OS no longer supported by the vendor. That's a tough position to be in, not only if a customer comes across a bug that is due to the OS, but it keeps you from advancing your desktop application forward.