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.
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.