ComNativeDescriptor is dependent on Windows #9291
Comments
JeremyKuhne
added
untriaged
|
Is the end goal for this better cross platform support in system.drawing and more shared code between winforms and system.drawing? |
|
@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? |
|
@AaronRobinsonMSFT, @elachlan the issue is around the 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 |
|
I can see why you mentioned runtime. It might make sense for it to be handled there. |
merriemcgaw
removed
the
untriaged
|
Related: dotnet/runtime#29125 |
WinForms hosts the the COM type descriptor. It has been updated to work with ComWrappers based objects- adding the check for them in TypeDescriptor. There are hard dependencies on Windows in the current implementation. We can potentially update to conditionalize these. dotnet/winforms#9291 tracks. There is no automated test as it would require adding a dependency upstream to WinForms.
WinForms hosts the the COM type descriptor. It has been updated to work with ComWrappers based objects- adding the check for them in TypeDescriptor. There are hard dependencies on Windows in the current implementation. We can potentially update to conditionalize these. dotnet/winforms#9291 tracks. There is no automated test as it would require adding a dependency upstream to WinForms.
We've recently enabled using
ComWrapperswith theComNativeDescriptor- thisTypeDescriptionProvideris what is used by the .NET runtimeTypeDescriptorfor COM objects.ComWrapperssupports other platforms (Unix/Mac), but our current implementation is dependent on Windows PInvokes. These are used both in theComNativeDescriptorcode directly and in support code, such as ourVARIANTimplementation.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
ITypeInfofor 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.
The text was updated successfully, but these errors were encountered: