ComNativeDescriptor is dependent on Windows

[JeremyKuhne]

We've recently enabled using ComWrappers with the ComNativeDescriptor- this TypeDescriptionProvider is what is used by the .NET runtime TypeDescriptor for COM objects.

ComWrappers supports other platforms (Unix/Mac), but our current implementation is dependent on Windows PInvokes. These are used both in the ComNativeDescriptor code directly and in support code, such as our VARIANT implementation.

We could remove some of these dependencies, but not everything. As a starting point it would probably be good to target COM types that have no complicated types (that is "primitives") exposed as properties (as described in the ITypeInfo for the type).

Converters that have dependencies on Windows APIs (directly, or indirectly through System.Drawing) would need to be conditionalized. It is unclear what would be the right answer for these. Do we skip a property when it has an IPicture or IFont, for example?

Ideally, we would get cross-plat primitive VARIANT handling from the .NET runtime (that would work with AOT/Trimming enabled). The notable Win32 dependency we have is with SafeArray handling. I haven't looked closely at those APIs, so I'm not sure how difficult it would be to manually implement.

Capturing this for the future. This is unlikely to get scheduled in the near term.

[elachlan]

Is the end goal for this better cross platform support in system.drawing and more shared code between winforms and system.drawing?

[AaronRobinsonMSFT]

@JeremyKuhne Is there a reason to explore this option? The comprehensive COM support is really the least of the issues with WinForms - the entire GDI+ subsystem would need to be stubbed out. Is focusing on cross-platform even remotely tenable or a goal?

[JeremyKuhne]

@AaronRobinsonMSFT, @elachlan the issue is around the ComNativeDescriptor, not cross plat support for Windows Forms in general. The type descriptor only exposes the members marked as properties and that often does not include anything other than "primitives". Even without System.Drawing support this could still be useful.

I don't think this is high priority and wouldn't do it without strong customer need, but I want to at least capture the details as I'm working on creating a PR in the runtime repo that will only allow through ComWrappers for the Windows platform.

[elachlan]

I can see why you mentioned runtime. It might make sense for it to be handled there.

[elachlan]

Related: dotnet/runtime#29125