Dynamic keyword not working against COM objects

[RickStrahl]

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 https://github.com/dotnet/corefx/issues/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;

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]

cc @AaronRobinsonMSFT

[AaronRobinsonMSFT]

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

cc @jeffschwMSFT

[AaronRobinsonMSFT]

@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]

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]

@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]

@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.

[AaronRobinsonMSFT]

cc @jaredpar for FYI. I now realize this issue should be in corefx (dynamic COM binder), but keeping it here since I already moved it once - boo.

[AaronRobinsonMSFT]

Specific error message for COM and dynamic PR: dotnet/corefx#40075

[sagebind]

Here's a class I am using currently as a workaround for this:

using System;
using System.Dynamic;
using System.Reflection;

// A small wrapper around COM interop to make it more easy to use.
private class COMObject : DynamicObject
{
    private readonly object instance;

    public static COMObject CreateObject(string progID)
    {
        return new COMObject(Activator.CreateInstance(Type.GetTypeFromProgID(progID, true)));
    }

    public COMObject(object instance)
    {
        this.instance = instance;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
        result = instance.GetType().InvokeMember(
            binder.Name,
            BindingFlags.GetProperty,
            Type.DefaultBinder,
            instance,
            new object[] { }
        );
        return true;
    }

    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
        instance.GetType().InvokeMember(
            binder.Name,
            BindingFlags.SetProperty,
            Type.DefaultBinder,
            instance,
            new object[] { value }
        );
        return true;
    }

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
    {
        result = instance.GetType().InvokeMember(
            binder.Name,
            BindingFlags.InvokeMethod,
            Type.DefaultBinder,
            instance,
            args
        );
        return true;
    }
}

And an example using it (in this case automating Photoshop):

dynamic application = COMObject.CreateObject("Photoshop.Application");
application.DisplayDialogs = 3; // transparent dynamic dispatch

[govert]

Here are two references from the C# 4.0 release in 2009 that describe the features implemented through dynamic binding support for COM and indexed properties in C# for COM libraries:

• https://blogs.msdn.microsoft.com/samng/2009/06/16/com-interop-in-c-4-0/
• https://blogs.msdn.microsoft.com/kirillosenkov/2009/10/20/indexed-properties-in-c-4-0/

As far as I know it is still not possible to explicitly create indexed properties in C#, which makes it hard to create a library that works the same as a PIA when referenced (thus implementing the dynamic binder support in user code as a workaround).

It really would help to light up these COM interop features again for .NET 5.

[OJacot-Descombes]

@sagebind: I extended your helper class by wrapping the returned objects recursively, if they are not primitive types.

private static object WrapIfRequired(object obj)
{
    if (obj != null && !obj.GetType().IsPrimitive) {
        return new COMObject(obj);
    }
    return obj;
}

I then apply this to the result (result = WrapIfRequired(result);) in TryGetMember and TryInvokeMember. It saves you from having to wrap returned objects manually.

---

Btw.: When dynamic was introduced in C# 4.0, the primary use case mentioned was to make it simpler to talk to COM objects like Word.Application. So, it seems logical to port it to .NET Core.