Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status of Dynamic against COM objects not working? #24246

Open
RickStrahl opened this issue Apr 25, 2019 · 6 comments

Comments

Projects
None yet
5 participants
@RickStrahl
Copy link

commented Apr 25, 2019

I'm working on porting one of my applications (Markdown Monster) to .NET Core 3.0 and it's going good except for my COM interop functionality that uses dynamic to access various COM components inside of the Web Browser control.

Using raw Reflection instead of dynamic works, but it would be a lot of code in my case that has to be converted to make the Interop with with the more clumsy syntax and type casting.

Specifically I'm getting back objects from the Web Browser control and then use dynamic to call other functionality. All of that doesn't work with .NET Core. I previously mentioned this and at the time it looked like there was already work underway to make this work in 3.0, with no fixes scheduled for 2.x. I talked about this in a blog post here. The original discussion I referenced that mentioned fixes for 3.0 where in dotnet/corefx#32630.

But now we're in 3.0 Preview and it's still not working.

Here's what I am doing:

// Get the JavaScript Ace Editor Instance
dynamic doc = WebBrowser.Document;

// fails
dynamic window = doc.parentWindow;

image

Replacing the code with manual reflection does work:

// this does
object window = ReflectionUtils.GetPropertyCom(doc, "parentWindow");

Status

There were previous issues open on this some time ago and at the time the word was that .NET Core 3.0 was going to fix this. It's not working on 2.x either at the time the call was won't fix for 2.x but will fix for 3.0.

Apparently it's not fixed in 3.0.

Is there any definite word on whether this will get addressed?

For me this is pretty big blocker in this app. I have tons of interop calls, and using dynamic is a key language feature that makes this code much more manageable (and also more performant due dynamic's internal caching etc) than using Reflection.

FWIW I already have an abstraction layer around the Editor/COM interop calls, but dynamic is such a core feature that it never occurred to me to abstract that further. I think if you want decent Windows Desktop support dynamic really should be working with COM objects.

Using latest .NET Core 3.0 Preview 4 SDK.

@jkotas

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

@AaronRobinsonMSFT

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

@jkotas Any chance we can move this issue to the coreclr repo?

cc @jeffschwMSFT

@jkotas jkotas transferred this issue from dotnet/corefx Apr 25, 2019

@jeffschwMSFT jeffschwMSFT modified the milestones: 3.0, Future Apr 25, 2019

@AaronRobinsonMSFT

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

@RickStrahl Given the current priorities and the possible workarounds this isn't support we are planning on adding in 3.0. However, this is something we will consider in a future release.

@RickStrahl

This comment has been minimized.

Copy link
Author

commented Apr 25, 2019

That's disappointing... but I get it. This encompasses a large set of functionality, but it's not like that code doesn't exist already in full framework. For COM this should probably even live in Windows.Compatibility most likely.

@AaronRobinsonMSFT

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

@RickStrahl Thanks for understanding.

This encompasses a large set of functionality, but it's not like that code doesn't exist already in full framework.

Indeed. I can assure you this wasn't an easy decision. In the spirit of transparency let me elaborate on the calculus used to make this decision.

The above assumption is correct and in many cases that fact is enough to let us port code over. However, in the case of dynamic supporting COM the amount of code required to add was on the order of thousands of lines of customized special cases. In general this is not much of an issue but adding this much code to the Dynamic Language Runtime (DLR) for .NET Core would have also required pulling in a substantial amount of testing as well. The combined cost of product work with testing debt was too much to pay in this release. There is also the unfortunate fact that many of the people with expert knowledge about the DLR are no longer on the .NET team which makes these kind of large feature changes difficult to perform in confidence. The final reason compounds all of the above and that is customer need. To be sure there are many COM users of the dynamic keyword but compared to other interop scenarios the desire for this one is smaller and even though the workaround is incredibly annoying and ugly - a workaround does exist.

There is no question this support can be added back in the future, but for right now it is just too expensive.

@govert

This comment has been minimized.

Copy link

commented Apr 26, 2019

@AaronRobinsonMSFT

This means the C# 4.0 COM interop work that implicitly uses 'dynamic' for IDispatch interfaces will not yet be available under .NET Core 3.0.

A consequence would be that most Office automation code cannot move from .NET Framework to .NET Core 3.0. This is because, even where Primary Interop Assemblies are used for early-bound COM access, the implicit interpretation of IDispatch as "dynamic" under C# is used extensively. For example, this code driving Excel works fine under C# 4 / NET Framework 4, but will not compile under .NET Core 3.0, even though everything seems to be early-bound and there is no 'dynamic' in sight:

using Microsoft.Office.Interop.Excel;

class Program
{
    static void Main(string[] args)
    {
        Application app = new Application();
        app.Visible = true;

        Workbook wb = app.Workbooks.Add();
        wb.Sheets[1].Name = "FirstSheet"; 
        //        ^^^^ Compiler error under .NET Core 3.0 as wb.Sheets[...] returns "object"
        //             Under C# 4 it would have been compiled and run as 'dynamic'
    }
}

This will be a show-stopper for moving a substantial class of Windows applications to .NET Core 3.0.

Please keep this issue open and high on your priority list for a future release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.