This seems to contrast MS when they released .NET but shied from using it in their own systems (though I might be wrong)
This seems to contrast MS when they released .NET but shied from using it in their own systems (though I might be wrong)
The performance difference between the garbage collected runtime and its C predecessor was too much and initial attempts at the rewrite in C# with Longhorn were a major fail.
Then there was Longhorn, which failed more due to internal politics than due to technical issues, as Midori later has proven just to be killed by management, as decribed by Joe Duffy postmortem reports.
WinRT/UAP/UWP are built on top of improved COM, and .NET has a native personality for them, using AOT compiler for WinRT/UAP (MDIL) and UWP (.NET Native).
Most of the new UWP stuff is written in .NET Native, with C++ taking care of the UWP runtime infrastructure, and the DirectX composition engine (Visual Layer).
The majority of Windows UI team UWP and FluentUI demos are usually done in .NET Native.
Silverlight was more of a platform than an "internal product" and it was based on .NET so it was only natural (it doesn't seem to have taken off though)
And yes .NET makes COM usable (well it is usable using MS libraries in C/C++, otherwise, forget about it :) )
IDispatch and variants were/are an abomination.
The problem that we have is that we have so much infrastructure around C++ that it is expensive to switch. Even if you get faster compile times or theoretically less memory management bugs, you may lose the productivity in other ways if the rest of your tooling isn’t there.
With C# you definitely pay a small cost in memory consumption and a decent cost in binary size vs. C++ though, which still matters.