The raisons d'être between the CLR (and C#) and Swift are entirely different.
Apple has explicitly set out to adopt Swift as a successor language to C, Objective-C, C++, and Objective-C++[0][1]. This stands in stark contrast to Microsoft's vision for the CLR, which was… to be a better Java, more or less? (Does anyone actually know what the .NET initiative was all about? Microsoft went absolutely ham on it in their branding, but the momentum unceremoniously fizzled out before Server 2003 went RTM.)
That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact. I'm told that there is in use a System C# dialect that generates native object code via a more production grade version of Bartok[3].
The original plan of .NET was also to replace everything, .NET was going to be the next COM, hence why there were still plenty of configuration settings named COM_ when the open source efforts started.
Also why since day one, it was polyglot, COM was part of the stack (as next step from VB 6 and MFC/ATL), and Managed Extensions for C++ were included (later replaced by C++/CLI in .NET 2.0).
The problem is that Microsoft isn't Apple, and WinDev couldn't care less about this, and stayed true to their COM/C++ tooling, similiarly when the Longhorn effort failed (mostly due to sabotage from Office/WinDev teams), Vista redid most of the .NET based ideas into COM/C++, and since Vista COM has been the main delivery mechanism for new Windows APIs (WinRT is yet another take on COM).
Bartok was used on the Windows Store compiler for Windows 8.x, via MDIL linker.
.NET Native on Windows 10, grew out of Project N, which was influenced by System C# used in Midori, not Singularity.
Technically the ".NET initiative" was all about web services. But not the modern kind, it was about SOAP. And I guess also Code Access Security-- a way to run untrusted (and even remote) code securely. Ahem, "securely".
The .NET Framework, CIL, and CLI/CLR and it's initial languages, C# and VB.NET, were in support of those technologies, but ended up being the only parts with real staying power.
I am a big fan of the .NET Framework (and it's evolution in .NET Core / .NET 5)-- so many rough edges of the Java runtime concepts and Java language concepts were polished, and a lot of new innovations were introduced (proper annotations, a framework for handling code isolation, a better reflection API, real runtime generics in .NET 2.0 and more).
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.
> That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact
Firstly, of course C# is used quite a lot within Windows in the user space.
I worked on some open source stuff around kernel level C# that was inspired by MSR's work here-- Singularity still used a very small core written in C++ iirc, we were interested in reducing the amount of unmanaged support code as much as possible as well as replacing the unmanaged c++ bits with unmanaged c#. That work grew into SharpOS. There was also a competing project called CosmOS. Lost to time now.
One of the guys who worked on Singularity's successor, Midori, has a nice multipage post-mortem write up.[0] Many design concepts have found their way into C#/.NET in the years since. However, unlike Singularity, Midori's source code was (unfortunately) never released.
> 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.
Apple has explicitly set out to adopt Swift as a successor language to C, Objective-C, C++, and Objective-C++[0][1]. This stands in stark contrast to Microsoft's vision for the CLR, which was… to be a better Java, more or less? (Does anyone actually know what the .NET initiative was all about? Microsoft went absolutely ham on it in their branding, but the momentum unceremoniously fizzled out before Server 2003 went RTM.)
That said, apropos .NET fitting into Windows, the work on Singularity[2] by MSR had a lasting impact. I'm told that there is in use a System C# dialect that generates native object code via a more production grade version of Bartok[3].
0: https://youtu.be/lgivCGdmFrw
1: https://developer.apple.com/swift/#:~:text=Swift%20is%20a%20....
2: https://www.microsoft.com/en-us/research/project/singularity...
3: https://en.wikipedia.org/wiki/Bartok_(compiler)