Provide ComObjectWrapper-only support for Dual COM interfaces

[jkoritzinsky]

As mentioned in #66674 (comment), there's customer desire for support for Dual interfaces in NativeAOT scenarios. Dual interfaces are IDispatch-derived interfaces that also include vtable entries after the IDispatch entries. The .NET runtime has historically invoked members on Dual interfaces via their vtable entries as that is significantly more efficient.

I propose that we add support for consuming Dual interfaces in the COM source generator though the vtable entries without adding any special support for IDispatch. This would also consumers of these APIs to move to using source-generated COM and supporting NativeAOT.

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As mentioned in #66674 (comment), there's customer desire for support for Dual interfaces in NativeAOT scenarios. Dual interfaces are IDispatch-derived interfaces that also include vtable entries after the IDispatch entries. The .NET runtime has historically invoked members on Dual interfaces via their vtable entries as that is significantly more efficient.

I propose that we add support for consuming Dual interfaces in the COM source generator though the vtable entries without adding any special support for IDispatch. This would also consumers of these APIs to move to using source-generated COM and supporting NativeAOT.

Author:	jkoritzinsky
Assignees:	-
Labels:	area-System.Runtime.InteropServices, untriaged, source-generator
Milestone:	-

[jkoritzinsky]

cc: @awakecoding would this proposal address being able to easily consume the RDP ActiveX API surface?

[awakecoding]

There is one big problem we've identified in Devolutions/MsRdpEx#97 - the old generated COM Interop produces C# accessors over IDispatch properties using MSIL, and there is no way to do the same in C# code. Interface definitions in C# code can't easily fix the problem, we're stuck being unable to provide source compatibility between the old COM Interop and the new as a result of this limitation.

[jkoritzinsky]

We're looking at addressing the properties support with #96502. Can you share an example of the IL that we can't represent in C#? Is it the case where the accessors aren't in the right order or is it something else?

[jkoritzinsky]

@JeremyKuhne since WinForms is the primary owner of the ActiveX experience in .NET, we wanted to get some input from you. What's the current experience with ActiveX and user code today?

[JeremyKuhne]

@jkoritzinsky I'm not sure exactly what you're asking for, can you elaborate?

[jkoritzinsky]

@JeremyKuhne what's the UX today for .NET/COM interop in the ActiveX APIs in winforms today, in particular where users can override methods to provide implementations, in particular AxHost.CreateInstanceCore?

For example, if a user were to return an ComWrappers-based COM object here, would that work well?

Also, are there places where you implement dual-interfaces on types that you pass into COM APIs? If so, are those using CsWin32 or manually-written ComWrappers-based APIs?

In particular, I want to make sure that if we were to implement support for consuming a dual COM interface through the vtable-based API surface, that we wouldn't break WinForms or get in the way of your code (as the primary consumers of dual COM interfaces are ActiveX consumers).

[StarRiver123]

There is one big problem we've identified in Devolutions/MsRdpEx#97 - the old generated COM Interop produces C# accessors over IDispatch properties using MSIL, and there is no way to do the same in C# code. Interface definitions in C# code can't easily fix the problem, we're stuck being unable to provide source compatibility between the old COM Interop and the new as a result of this limitation.

Hi, May I ask a question ? Is There any way to use other deverloper`s tlb file in the nativeAot ?