You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to support trimming/AOT we'll be moving our OLE interactions to native pointers and ComWrappers. In doing that we'll need to handle incoming IDataObject pointers. This issue is to capture some of what this entails.
When we get IDataObject* from OLE (for drag/drop and clipboard) we have a number of cases:
The IDataObject* is a CCW from COM interop.
The IDataObject* is a CCW from ComWrappers
The IDataObject* is neither (originally created in native code - that is originating outside of .NET).
In the first case we need to recognize that and unwrap the managed object if it was one that we populated. It is possible someone else may have manually P/Invoked data out and we need to be aware of it and consider if we're breaking any casting support that COM interop provides.
The second case is much the same, we want to get the original DataObject out and not try and wrap in a ComWrappers RCW.
Third case is a bit more tricky. Historically we have wrapped this in a COM interop RCW. This allows dynamic casting of any supported COM interface via QueryInterface. While we can create a ComWrappers RCW, we wouldn't get this behavior anymore in that case.
Because of this lack of dynamic casting we'll have to either use built in COM when it is available and/or allow configuring the behavior based on config switches.
The text was updated successfully, but these errors were encountered:
Ole32.ReleaseStgMedium uses System.Runtime.InteropServices.ComTypes. So I can't convert it to CsWin32. Should ReleaseStgMedium be added to the System.Runtime.InteropServices namespace via runtime? My quick google sees quite a few people implementing their own DllImport where it would make sense to just expose it via runtime.
In order to support trimming/AOT we'll be moving our OLE interactions to native pointers and
ComWrappers
. In doing that we'll need to handle incoming IDataObject pointers. This issue is to capture some of what this entails.When we get
IDataObject*
from OLE (for drag/drop and clipboard) we have a number of cases:IDataObject*
is a CCW from COM interop.IDataObject*
is a CCW fromComWrappers
IDataObject*
is neither (originally created in native code - that is originating outside of .NET).In the first case we need to recognize that and unwrap the managed object if it was one that we populated. It is possible someone else may have manually P/Invoked data out and we need to be aware of it and consider if we're breaking any casting support that COM interop provides.
The second case is much the same, we want to get the original
DataObject
out and not try and wrap in aComWrappers
RCW.Third case is a bit more tricky. Historically we have wrapped this in a COM interop RCW. This allows dynamic casting of any supported COM interface via
QueryInterface
. While we can create aComWrappers
RCW, we wouldn't get this behavior anymore in that case.For example in
CreateDragEventArgs
:Because of this lack of dynamic casting we'll have to either use built in COM when it is available and/or allow configuring the behavior based on config switches.
The text was updated successfully, but these errors were encountered: