upvote
I'm assuming but the versions are not fully backwards compatible so you can't just ship the latest version, they would need to ship all. There almost ten .NET versions released after the one which ships in Windows. And a new version is released every year.

The author does mention that .NET does have distribution options which don't require the user to install the runtime. You can have it package the full runtime with your build, either as a bunch of files, a self-extracting executable, or a standalone AOT-compiled native executable.

The author mentioned that the AOT-compiled executable is 9 MiB which is unacceptable to them. The other options will need even larger. Personally I don't see 9 MiB as a big deal especially when the author would rather go with Electron which is larger at worst (bundled Chromium) and only inefficient at best (system WebView).

reply
Windows update is how it used to work and it's terrible. An update breaks old apps, or downloads a every single version (not feasible). Who would want to run windows update to install a new app?

It's just a bad idea. Today we just pack in the DLLs and it just works.

reply
An update breaks old apps

That's something which is MS' problem; they're supposed to be the company who is best at backwards compatibility, but clearly have strayed from that path.

reply
No one suggesting using Windows Update to install new apps, they are suggesting the current .Net framework should be elevated to a first class Windows citizen and included with Windows installs and updated with Windows Update, and that seems like and obvious idea that should have been implemented when .Net Core became .Net.
reply
.NET versions are not fully backwards compatible. Would you like every Windows install to ship with over ten versions of the .NET runtime?
reply
We would like it to be good. Whichever way to achieve goodness - either be backwards compat, or ship all the stable versions, I don't care but the current situation is silly. Apple gets flack for this and that, but their UI toolkit situation is lightyears ahead; you just pick the OS version you want to target in your app build settings and it will work that way for everyone.
reply
100 MB per runtime, for everyone, and the majority of them are out of support. Is that really the good option? Why not the option the author dismissed: a 9 MB AOT-compiled executable which doesn't need a separate runtime?
reply
There are a few reasons that I can see why they don't integrate the latest .net.

First is that the security model changed with .net 5. Next is that they subsume Mono/.net core into the foundation of the language and this cost them them the ability to support Windows native development, specifically anything to do with Win32 API.

If you look at .net 10 and compare that to .net 5 you can see that they are trying to reintegrate the Win32 API but now it is in the all new Microsoft namespace.

The amount of change is too significant to act as a drop in replacement for the original .net framework. Maybe they could have gone a side-by-side installation, but the rapid development of The NET Framework I think made it too hard to tie to an operating system update. They wanted to free it from that update cycle of once a year or every two years and allow the development to progress rapidly at the cost of having to download it and install it each time.

reply
Side by side is what I'm asking for. Just like there's WebView (IE-based) and WebView2 (Chromium-based, evergreen, updated every 4 weeks).

I don't think the rapid development cycle argument holds water, when they're shipping a new WebView2 every month.

reply
There’s two versions of .NET. One is “legacy”, which is stable as anything and bundled with the OS. The other is “Core”, that only has support for three years and isn’t 100% compatible. The reason the latest .NET runtime isn’t bundled is the above: the stable version is bundled.
reply
Core is compatible with non deprecated apis.

That’s why they had .NET 5im stead of .net core 5

reply