Earlier quoted context omitted.
I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications. VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (…
I think we need to distinguish between COM and OLE/ActiveX here. COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. OLE is much more challenging, because the UI framework needs to be aware of it, and because it's built on Win32 UI primitives - so any framework that doesn't use those is going to have issues much like WPF (Qt is anoth…
I understand that's because .NET components loaded into a native process via COM are done so in-proc but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. I also understand (but am unsure) about what this means for AppDomains.
.NET Core simplifies things considerably: by being utterly broken when it comes to COM support and generally requiring each .NET Core program to have its own independent process rather than supporting multiple AppDomains in the same process (okay, that's a bit of hyperbole: .NET Core supports strongly-typed COM objects but they removed support for using `dynamic` with late-bound COM objects - and I can't find any documentation regarding loading .NET Core components via COM into a native VB6/C++ process.
> But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
I understand the default for .NET Framework application projects is still AnyCPU but a new option called "Prefer 32-bit" is selected by default. Whereas for library projects and all .NET Core projects the default is AnyCPU ("Prefer 32-bit" is only an option for *.exe projects).
> If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own).
> That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
I understand the reason was because very few applications in the wild depended on this functionality (that's what Microsoft's telemetry in Windows is for) - I think the only real application that made full use of this was MS Binder (rip 2002) - and I only ever got annoyed at the times when Internet Explorer would load Office Word or Excel directly into the browser shell.
Office 2007's radically redesigned UI required much more screen real-estate - whereas Office's support for being loaded into an OLE window was back when people were running at 640x480 or 800x600 (if you were lucky!) and Office had 16px-sized toolbar buttons - which is another reason to avoid wasting developer time working on it.