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.
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.
.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.
The issue is in supporting older windows versions - which sadly is still a reality for most large-scale app developers.
https://github.com/dotnet/core/blob/main/release-notes/10.0/...
.NET 10 supports a Windows 10 build from 10 years 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.
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.
.NET versions are faster outdated then .Net Framework 4.8
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.
You're talking about .net for server applications right? The discussion above is for client apps being distributed for windows endusers.
Just ship a self contained build?
We have a small MAUI part of the application, it's not massive but it's working fine with .Net Upgrades.
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.