Support COM objects with dynamic keyword

[elinor-fung]

This is a port of the support (which is in Framework and the IronLanguages DLR) for using the dynamic keyword with COM objects.

The actual support is in Microsoft.CSharp. The tests are under coreclr, since that is set up to test against a native COM server. I did a couple passes to make the ported sources fit in the runtime repo (I'm sure there's more that could be done).

The vast majority of this is a simple copy of the previous support. The commits in this PR are:

• Straight copy of all the sources (first commit 21a9e9a)
• Changes (next 15 commits) to get it building and working
• New tests
• Additional clean-up/consolidation to make it fit a bit better in this repo.

cc @jaredpar @cston

Resolves #12587

[stephentoub]

This prevents ComEventsSink in Microsoft.CSharp.dll from being trimmed out. Is it being accessed by reflection somewhere and that's why this is needed?

[elinor-fung]

Parts of it will be accessed by whatever COM server is firing the events for which a handler has been added. Specifically, it is the ComEventsSink's implementation of IDispatch that is not explicitly used (directly or via reflection), but is necessary for handling COM events.

Is there a better way to prevent that from being trimmed out? I know there is PreserveDependency, but since we are not actually the ones that call into it, we don't actually have another method that is using it.

[stephentoub]

Thanks for the explanation. I think what you have is the best we can currently do. That said, are you actually seeing the interface implementation get removed? I didn't think the linker would do that if the interface is used anywhere, but my knowledge may be out of date.

[elinor-fung]

Yeah, I hit this because the implementation of IDispatch.Invoke was getting removed.

[jkotas]

dotnet/linker#936 ?

[VSadov]

I left some comments, but there is nothing that is blocking. The change looks good.

• I like that the remoting/proxy pieces are no longer needed.
• It is nice to see that most IL-generated helpers (like ConvertByrefToPtr flavors) are gone. Maybe one day we can get rid of the helpers that wrap CALLI as well.

LGTM

[jaredpar]

@VSadov

It is nice to see that most IL-generated helpers (like ConvertByrefToPtr flavors) are gone. Maybe one day we can get rid of the helpers that wrap CALLI as well.

Is this something that function pointers will help out with? @333fred

[VSadov]

@jaredpar - Yes, I think the whole point of function pointers is to make CALLI expressible in C# and handle scenarios like this.