Support COM objects with dynamic keyword by elinor-fung · Pull Request #33060 · dotnet/runtime

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung · 2020-03-02T19:28:30Z

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 · 2020-03-02T20:36:10Z

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?

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.

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.

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

dotnet/linker#936 ?

Collection tests

Reconcile Variant used for dynamic support with shared source

VSadov · 2020-03-04T20:17:40Z

 /// managed delegates to COM's connection point based events.
 /// </summary>
- internal class ComEventsSink : IDispatch, ICustomQueryInterface
+ internal partial class ComEventsSink : IDispatch, ICustomQueryInterface


IDispatch, ICustomQueryInterface [](start = 43, length = 32)
Nice! In olden time this had to use IReflect/RealProxy stuff to pretend it implements interfaces.

Fix delegate removal by index Remove unnecessary comments and attributes

VSadov · 2020-03-04T23:45:32Z

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

Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

jaredpar · 2020-03-05T17:26:18Z

@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 · 2020-03-05T20:30:51Z

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

elinor-fung added 16 commits March 2, 2020 11:21

Copy ComInterop from IronLanguages/dlr. Add to Microsoft.CSharp
21a9e9a

Remove netfx files. Remove netcoreapp suffix from file names.
fe65c72

Update namespaces
45fba98

Use SR.Format
0bfa713

TypeUtils.IsComObject -> Marshal.IsComObject
1e7d474

AstUtils.Convert -> ComInterop.Helpers.Convert
4c60f24

AstUtils.Constant -> Expression.Constant
ada5d0b

Add System.Reflection.* references and allow unsafe
92cfcfb

Use built-in type aliases. Suppress warning for generated code.
63ea5d5

Use Array.Empty
3da7008

Fix style violations
b19a5be

Remove usage of ContractUtils and System.Security.Permissions
19a2447

Make classes internal
e146fd2

License, style, auto-format
48d9e26

Set ENABLECOMBINDER. Fix usage of ComBinder in CSharp*Binder
8fe1dad

Move error strings to resx. Remove unused strings
30a1bd1

elinor-fung force-pushed the comDynamicSupport branch from 12e2114 to d1fd507Compare March 2, 2020 20:24

stephentoub reviewed Mar 2, 2020
View reviewed changes

Comment threadsrc/libraries/Common/src/System/Runtime/InteropServices/ComEventsMethod.cs Outdated

stephentoub reviewed Mar 2, 2020
View reviewed changes

Comment threadsrc/libraries/Common/src/System/Runtime/InteropServices/Variant.cs Outdated

stephentoub reviewed Mar 2, 2020
View reviewed changes

danmoseley added the area-Interop-coreclr label Mar 2, 2020

elinor-fung added 9 commits March 2, 2020 15:41

Add test project
2c17d48
Collection tests

Basic tests
ae2f127

Fix using COM events
8b3409f

Event test
e32e6fc

Parameters test
dffd54f

Move System.Runtime.InteropServices.Variant to shared directory
aa7afa5
Reconcile Variant used for dynamic support with shared source

Use nameof
d9b7424

Use Unsafe.AsPointer instead of creating dynamic assembly for method
1bf8c6a

Move ComEventsMethod and ComEventsSink to shared directory
c504b73

VSadov reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/libraries/Microsoft.CSharp/src/Microsoft/CSharp/RuntimeBinder/ComInterop/ComObject.cs Outdated

VSadov reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/libraries/Microsoft.CSharp/src/Microsoft/CSharp/RuntimeBinder/ComInterop/Helpers.cs

VSadov reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/libraries/Microsoft.CSharp/src/Microsoft/CSharp/RuntimeBinder/ComInterop/Helpers.cs

cston reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/coreclr/tests/src/Interop/COM/Dynamic/Program.cs Outdated

cston reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/coreclr/tests/src/Interop/COM/Dynamic/Server/DispatchImpl.h Outdated

cston reviewed Mar 4, 2020
View reviewed changes

Comment threadsrc/coreclr/tests/src/Interop/COM/Dynamic/Program.cs

PR feedback
74613c1
Fix delegate removal by index Remove unnecessary comments and attributes

VSadov approved these changes Mar 4, 2020
View reviewed changes

PR feedback
f520012
Remove exclusion list for dynamic member debug view Simplify handling of ref enum parameter for events

cston approved these changes Mar 5, 2020
View reviewed changes

elinor-fung mentioned this pull request Mar 5, 2020
Marshal.GetIDispatchForObject should be implemented on platforms with COM support #33217
Closed

AaronRobinsonMSFT approved these changes Mar 5, 2020
View reviewed changes

elinor-fung merged commit ac219a0 into dotnet:masterMar 5, 2020

elinor-fung deleted the comDynamicSupport branch March 5, 2020 23:02

333fred mentioned this pull request Mar 6, 2020
Open Issues in "Function Pointers" dotnet/roslyn#39865
Closed
18 tasks

sandreenko mentioned this pull request Mar 6, 2020
Interop\COM\Dynamic\Dynamic\Dynamic.cmd fails on x86 #33276
Closed

AaronRobinsonMSFT mentioned this pull request May 29, 2020
Using -comObject in pwsh7 is extremly slow compaired to powershell 5.1 #36944
Closed

daxian-dbw mentioned this pull request May 29, 2020
Refresh and enable the 'ComBinder' code in PowerShell PowerShell/PowerShell#12842
Closed

AaronRobinsonMSFT added this to the 5.0 milestone Jun 3, 2020

AaronRobinsonMSFT mentioned this pull request Jun 3, 2020
Activator.CreateInstance fails on GetTypeFromProgID on .NET Core 3.1 #37362
Closed

MichalStrehovsky mentioned this pull request Jun 12, 2020
IDynamicInterfaceCastable and reflection #37787
Closed

daxian-dbw mentioned this pull request Jul 29, 2020
Refresh and enable the ComInterop code in PowerShell PowerShell/PowerShell#13304
Merged
14 tasks

AaronRobinsonMSFT mentioned this pull request Oct 30, 2020
Dynamic keyword not working against COM objects #12587
Closed

This was referenced Nov 13, 2020
Excel-DNA Roadmap Discussion Excel-DNA/ExcelDna#189
Open
When can we have a version for .Net Core? Excel-DNA/ExcelDna#175
Closed

ghost locked as resolved and limited conversation to collaborators Dec 10, 2020