Plan or recommendations for [GeneratedComClass] support when consuming Windows APIs in AOT apps?

[mqudsi]

For a very brief window of time, .NET "Core" apps targeting a specific -windows10.0.xxxxx tfm had full COM interop (both cw and rcw) support without needing the developer to re-define all com interfaces to interface with them. But now with AOT support disabling runtime com marshalling and the switch to [GeneratedComInterface] and [GeneratedComClass], we (or at least, some of us) are back at the point where we need to recreate the definitions of any COM classes we wish to consume or expose because the Microsoft.Windows.Sdk.Net classes all rely on the old runtime com interop model.

Is there a plan for either shipping [GeneratedComInterface]-annotated interface definitions or else providing a new source code generator that would create an XxxNative version of all WinRT/COM interfaces a [GeneratedComClass] derives from so that we aren't coding like it's 2002? (Of course the problem with the latter is that a lot of COM interface wrappers rely on marshalling features that the new source generated com interop doesn't support without custom marshallers.)

Thank you kindly!

(If this is the wrong repo for this question, then mea culpa and I would appreciate being pointed in the right direction.)

[dongle-the-gadget]

I made a PR, #1858 but it was currently blocked due to a .NET issue

[mqudsi]

Hey @dongle-the-gadget! I actually ended up finding that PR later last night, and have been trying to figure out how to work around it with the steps detailed in #1722.

I see that it works on the [GeneratedComClass]-annotated class derived from WinRT interfaces rather than requiring [GeneratedComInterface] annotations on the upstream interface declarations. Does that mean that it can handle syntax not currently supported by the COM source generators when it's indirectly (recursively) accessible from the API entry points? e.g. dotnet/runtime#66674 details how properties are not yet supported (and I just commented on there asking if event support is on the table)?

For example, if I want a [ComGeneratedClass] implementing IBackgroundTask, the definition of which declares only a single method with no fancy syntax, but takes a (COM/WinRT object) that contains properties and events not currently supported by [ComGeneratedInterface] (void Run(IBackgroundTaskInstance taskInstance)). Is that OK?

[dongle-the-gadget]

No, it won't work. What [GeneratedComClass] does is that it gathers all interfaces that implements [GeneratedComInterface] and puts it in a list that we can access so we can marshal it through COM.

However, CsWinRT already has the ability to manually marshal WinRT interfaces. What you need to do is make the class that implements such interfaces partial, and then use MarshalInterface<T>.FromManaged to get the native WinRT object.

[mqudsi]

Thank you, that did the trick. For some reason I was actually under the impression that MarshalInterface<T> was not available with runtime marshalling disabled.