Proposal: Simplify the C# development experience when using classic COM interfaces needed for WinRT objects

[marb2000]

Some interfaces, like IWindowNative, IInitializeWithWindow, IBufferByteAccess, or IDesktopWindowXamlSource, are classic-COM interfaces requested to consume a few WinRT APIs from Win32. For instance, the WinRT API File­Open­Picker looks for a Core­Window on the current thread to serve as the owner of the dialog. But when running in Win32 (WinUI 3 in Desktop), the APIs crash because there is not Core­Window. The solution is to use the IInitialize­With­Window interface to allow a Win32 app to specify an explicit window handle.

These interfaces aren't defined in WinMD files (they are classic-COM), so C#/WinRT can't generate C# projections. As a consequence, C# developers require to implement a pattern to use them in their apps.
You can find an example here.

This proposal is to simplify the development experience when using COM interfaces needed for frequently used WinRT APIs in Win32. Below is the current top list of these interfaces:

Interface	Priority
IWindowNative	must
IInitializeWithWindow	must
IBufferByteAccess	must
IDesktopWindowXamlSource	nice

[Scottj1s]

Definitely as a baseline, we should hand-roll these projections. In addition, it's possible that a cswinrt project could use a source generator to 'reflect' on a developer's [ComImport] interfaces and attempt to project these. At a minimum, the cswinrt generated As<>() helper and the new ICastableObject support could both assert that the target interface has a projection, and if not issue a helpful diagnostic.

[Scottj1s]

See cswinrt proposal for projecting ComImport interfaces:
microsoft/CsWinRT#302

[weltkante]

Not mentioned in OP so I'd like to request ensuring compatibility between WinUI SwapChain technology and custom projections of DXGI/D3D (I assume you won't be producing an official projection of those APIs). Interleaving UI with swapchain rendering was one of the more unique features of the UWP UI framework and I'd like to keep it working when transitioning to WinUI, so please keep it in mind when building the new interop.

[Scottj1s]

Direct ComImport interop support has been added to C#/WinRT (microsoft/CsWinRT#333). This will support all existing ComImport scenarios without requiring custom projections, except for a very few cases that intentionally cross the COM/WinRT streams (e.g., IGraphicsEffectD2D1Interop). DXGI/D3D interop should work as before.

@marb2000 - you should be able to remove your custom projections from https://github.com/microsoft/WinUI-3-Demos/blob/master/DemoBuildCs/

/cc @ryalanms, to consider removing similar hand-rolled IWindowNative/IInitializeWithWindow projections from WinUI.

[Scottj1s]

For the Microsoft.WinUI.dll projection assembly, consider:

• Where possible, defining interop interfaces in IDL and generating projection code for them to handle marshaling
• Where not posssible, adding ComImport definitions with hand-rolled wrappers to handle marshaling

[Scottj1s]

Support for this has been implemented in C#/WinRT: https://github.com/microsoft/CsWinRT/pull/830/files

Closing this as there is an internal issue (28988767) tracking enabling this support in the Windows SDK projection