Open JeremyKuhne opened 1 year ago
The code here leverages the auto-generated IConnectionPointContainer from COM interop. If built-in COM interop is not available we'll have to figure how to replace this.
The IConnectionPointContainer
interface is tough in general. I do think the mechanics of COM events in .NET are hidden and often crop up in places that aren't always obvious. I agree this is something the Interop team will need to consider how to address this, particularly when we start rewriting TlbImp
to support .NET Core and COM source generators.
/cc @dotnet/interop-contrib
particularly when we start rewriting TlbImp to support .NET Core and COM source generators.
@AaronRobinsonMSFT this is of particular interest to us for the ActiveX Control scenario. We might also need to update the tool that generates the AxHost
implementations on top of these.
cc: @Shyam-Gupta
I'm currently doing handwritten bindings (#10583) and noticed ConnectionPointCookie (which is related to the interface mentioned here) does not support COM source generators all, something is broken in the implementation here. When I pass an object implementing both a source generated and classic version of the same IDispatch interface ConnectionPointCookie rejects to connect.
Going forward, I think the main question for these event interfaces will be where the IDispatch support will live
The code here leverages the auto-generated
IConnectionPointContainer
from COM interop for access to managed events. If built-in COM interop is not available we'll have to figure how to replace this.In this particular case it is only done for user controls, but we probably will need to provide this functionality in general for Control. I'm not sure how prevalent this is for our users that would want to use AOT.
cc: @AaronRobinsonMSFT @lonitra