ComWrappers support

[kant2002]

I want to raise questions about plans for adding ComWrappers support in WinForms.
This make WinForms application IL trimming friendly. For me that would be big win for NativeAOT, but I understand that this is not priority.
Work in .NET repository started dotnet/runtime#54636 and I think similar approach to some degree can happens here.

I initially try to find simplest interfaces where this can be tested, but everything so intermixed with ActiveX support, so I do not know where to start.
So far easiest targets to get started is following

• IPicture, IStream, IPersistStream.
• IClassFactory2
• IMallocSpy

Each these interfaces has their own challenges

IPicture, IStream, IPersistStream

Initially can be implemented for Cursor class only. IPicture used a lot in ActiveX code and that part is extremely problematic and maybe require usage of IDynamicCastable or similar complicated approach. Also probably it will require OleCreatePictureIndirect split of implementation on two parts, one for ComWrappers, second is for ComWrappers, and that would be for some time, since ActiveX seems impenetrable target for now.

IClassFactory2

This is very limited in usage and can be used for probing ground how to start make ActiveX support friendly for ComWrappers. Interface in itself not a problem, but CreateInstanceLic return object instance which as far as I understand, should be universal RCW. I personally may go with temporary using existing COM infrastructure, using Marshal.GetObjectForIUnknown until better solution arise.

IMallocSpy

This interface used only for tests, so not a big win in terms of implementation. Maybe good candidate to prepare tests for world without no built-in COM.

Testing

As mentioned in PR for System.Drawing.Common, they have to support .NET Core 3.1 and this requires a bit of changes in testing. I'm not sure how applicable this concerns for this repo, and how do you manage older .NET Core. Require discussion too.

Also a lot of tests rely on the built-in COM infrastructure so this is also should be factored somehow.

[dreddy-work]

@JeremyKuhne would be right person on winforms team to take this discussion further.

[JeremyKuhne]

We do want/intend to move to function pointers for COM, it is just a matter of resource allocation. If folks are interested in contributing to make this happen we'd welcome it. Tests will be important and depending on risk and timing some changes might have to go into .NET 7.

[kant2002]

@JeremyKuhne Yes. I potentially willing to contribute in that area.
I have further questions which will affect my contributions. Does this repo should take into account .NET 3.1? If yes, then since ComWrappers do not support .NET 3.1 tests should run again .NET 3.1 and NetCoreAppCurrent (?). I may need help in that area.
If you have some other specifics which I may not know, would be good to have them listed.

What's better way to discuss path how to implement ComWrappers, just send PR or better start with issues?

[RussKie]

Does this repo should take into account .NET 3.1?

To service .NET Core 3.1 we need to meet the servicing bar, and at this stage I can't see we will. So changes will go into .NET 6.0 onwards.

What's better way to discuss path how to implement ComWrappers, just send PR or better start with issues?

Yes, a draft PR would be a good start.

Thank you

[kant2002]

So changes will go into .NET 6.0 onwards.

Quick question to double-check that I understand correctly. For me this is means that I should not worry about .NET 3.1 and can just change code. No split in project files like it was in dotnet/runtime#54636. Correct?
I have feeling that you answer significantly simplify my life, but cannot believe that.

[JeremyKuhne]

For me this is means that I should not worry about .NET 3.1 and can just change code.

Yes, we only build the next version from our main branch. @RussKie was saying that if you wanted to make the same changes to 3.1 you would have to do so in the release branch for that version and that it wouldn't be something that would meet the servicing bar.

So you do not have to worry about any other .NET versions in main other than .NET 6.

[kant2002]

Most work in ComWrappers would be like in #5174 where private instances would be used to provide access to COM instances.
This would work for handful of places, but not in WebBrowser. Reason for that, is that .NET allow cast __ComObject to different interfaces. In case of WebBrowser, this is utilized to have access to additional services out of ActiveX instance of WebBrowser. Example https://github.com/opentween/OpenTween/blob/55081d1f83daea1799f9e1aacecae3c1cb4578bf/OpenTween/WebBrowserController.cs#L303-L306

All options which I see is not good one.

Option 1

Claim that WebBrowser would not work in AOT scenarios. With all love which Web has it is not ideal scenario.

Option 2

Support only COM interfaces what's in WinForms on internal wrapper and turn blind eye on an issues. Not an option likely, but let's pretend that it is.

Option 3

Add additional API which will provide support for these cases. Maybe expensive.

Option 4

Get rid internally on reliance on ActiveXInstance and return __ComImport on request, essentially saying that this property is not AOT-friendly. Still unclear what to do with cases similar to OpenTween.

So I would like to at least start discussion early, so when time comes, I would be better prepared to implement that.
I probably has to ask @AaronRobinsonMSFT to join discussion, because maybe I miss something which was already discussed.

Also I suppose this kind of issues may affects WebView2, but maybe it's too pessimistic to think like that.

[RussKie]

Claim that WebBrowser would not work in AOT scenarios. With all love which Web has it is not ideal scenario.

The WebBrowser control is all but officially deprecated, since it is based on the old IE engine. The current official guidelines are to migrate to the Edgium-based WebView2 control.