More trimming friendly DragDrop

[kant2002]

Currently DragDrop process starts with DragDropEffects DoDragDrop(object data, DragDropEffects allowedEffects) which inside perform dispatcherization of the supported interfaces and objects. Sometimes this may means that we rely on Built-in COM support for cast of the interfaces.

Built-in COM support maybe disabled in modern .NET and do not supported in NativeAOT flavor of CoreCLR. I propose provide API which put responsibility of AOT supported casting on the consumer side by introducing typed version of the method.

public class Control
{
+ [BuiltInComDragonsHere]
  public DragDropEffects DoDragDrop(object data, DragDropEffects allowedEffects)
+ public DragDropEffects DoDragDrop(System.Runtime.InteropServices.ComTypes.IDataObject data, DragDropEffects allowedEffects)
+ public DragDropEffects DoDragDrop(System.Windows.Forms.IDataObject data, DragDropEffects allowedEffects)
}
public class ToolStripItem
{
+ [BuiltInComDragonsHere]
  public DragDropEffects DoDragDrop(object data, DragDropEffects allowedEffects)
+ public DragDropEffects DoDragDrop(System.Runtime.InteropServices.ComTypes.IDataObject data, DragDropEffects allowedEffects)
+ public DragDropEffects DoDragDrop(System.Windows.Forms.IDataObject data, DragDropEffects allowedEffects)
}

This would be considered source breaking change.

/cc @weltkante since you maybe interested in giving feedback on this.

[RussKie]

Can you please elaborate on how you envision this API to used? And how it will affect consumers of the existing API?

[kant2002]

This API should be used instead of similar method DragDropEffects DoDragDrop(object data, DragDropEffects allowedEffects) which are already exists. Currently this method can accept

1. Random .NET object
2. Inheritor of S.W.F.IDataObject
3. Inheritor of S.R.I.ComTypes.IDataObject
4. Inheritor of type which has same shape as S.R.I.ComTypes.IDataObject (built-in com translate that type to S.R.I.ComTypes.IDataObject)

I want new API methods cover items 2 and 3 respectively and get rid of item 4. Let's talk about item 1
Under the hood if I pass random .NET object, then it is wrapped into S.W.F.DataObject, it would be trivial change in order to support be explicit.

Item 4 is most important in my opinion. This scenario will never work with built-in COM disabled and inside NativeAOT. Having method which works only sometimes is problematic IMO. So I want push responsibility for conversion of COM methods to user code, and out of WinForms code. Statements is like this. If you use 2 new API you are safe in NativeAOT/without built-in COM. If you use old method, you on your own. Most likely it would work, but if not, that's not our problem.

I expand API proposal to indicate that we need to add some attribute to existing method, so ILLinker tooling (or some else) would complain. I do not know exact attributes. Maybe RequiredDynamicallyAccessibleCode.

For consumers

Item 2 and Item 3

nothing should be done. But this is source code breaking change, since different method would be used.

Item 1

Before

int x = 1;
DoDragDrop(x, DragDropEffects.All)

After

int x = 1;
DoDragDrop(new DataObject(x), DragDropEffects.All)

Item 4

Before

var x = new CustomObjectWithSimilarComType();
DoDragDrop(x, DragDropEffects.All)

After

var x = new CustomObjectWithSimilarComType();
DoDragDrop((System.Runtime.InteropServices.ComTypes.IDataObject)x, DragDropEffects.All)

or even better

var x = new CustomObjectWithSimilarComType();
DoDragDrop(new SpecialDataObjectForCustomObjectWithSimilarComType(x), DragDropEffects.All)

[kant2002]

@RussKie do you need additional information?

[RussKie]

The team will discuss in one of the upcoming triages.

[kant2002]

@RussKie are the team has possibility to discuss this issue on the meetings?

[RussKie]

@kant2002 thank you for the nudge. Yes, absolutely! I've been away for few weeks, and just got back. Still catching up...

/cc: @merriemcgaw @dreddy-work @JeremyKuhne