> There's definitely things they tried to improve on that... weren't really improvements. The way "assemblies" are matched in .NET is much more sophisticated- the goal there was to try to kill DLL hell. It evolved into the Global Assembly Cache, which is sort of the Windows Registry of DLLs. Not a huge fan of those bits.
The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752
The assembly redirection hell has also been greatly reduced there.
There is something similar to the Global Assembly Cache for .NET Core. This allows WSUS to automatically upgrade the .NET runtime installed on the system.
Not really. You can upgrade the framework with Windows Update, or by just going to dotnet.microsoft.com and downloading the latest installer. Applications can ship their own copy of the framework or depend on the system copy. The framework does include some core/system libraries, but other applications can’t install their crap system-wide (which was possible with the GAC).
Thats just framework dependent upgrades. .NET core and beyond allows for side by side installations of with different assembly versions where in .NET framework they shared a GAC.
Yeah I didn't think it had, but I've not done too much with Core/5+ yet. I want to use it but I end up just using Typescript/Node by default. I do need to get into the habit of investigating using CLR when a bit more performance or lower latency is required, instead of jumping past it to systems level with C++/Rust/Go.
The Global Assembly Cache did not make the jump to the modern .NET (Core). There was the thing called `dotnet store`, but it’s broken since .NET 6: https://github.com/dotnet/sdk/issues/24752
The assembly redirection hell has also been greatly reduced there.