.NET 6 IDispatch client implementation crash

Question

.NET 6 has trouble calling its own IDispatch objects, if marshaled.

To reproduce:

if (Array.IndexOf(Environment.GetCommandLineArgs(), "/s")>=0) //Server
{
    Thread t = new Thread(new ThreadStart(() =>
    {
        Hello h = new Hello();
        new RunningObjectTable().Register("HelloTest", h);
        Thread.Sleep(1000 * 3600);

    }));
    t.SetApartmentState(ApartmentState.MTA);
    t.Start();
    Thread.Sleep(1000 * 3600);
}
else //Client
{
    object o = new RunningObjectTable().Get("HelloTest");
    IHello h = o as IHello;
    int f = h.Foo();
    Console.WriteLine(h);
}

[ComImport]
[Guid("00020400-0000-0000-C000-000000000046")] //IID_IDispatch
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
[TypeLibType(TypeLibTypeFlags.FDispatchable)]
public interface IHello
{
    [MethodImpl(MethodImplOptions.PreserveSig | MethodImplOptions.InternalCall)]
    [DispId(1)]
    public int Foo();
}

public class Hello: IHello
{
    public int Foo()
    {
        Debug.WriteLine("Hello from server");
        return 19;
    }
}

Run the program with /s, that's the object server. Then run another copy to become the client.

The method invocation line in the client crashes with "Member not found" - HRESULT 0x80020003, DISP_E_MEMBERNOTFOUND. Normally it would mean a bogus DISPID, but where would the discrepancy possibly come from?

One minor infraction in that code is that the interface is decorated with the IID of IDispatch. With a custom IID, as COM prescribes, it doesn't even unmarshal as the dispinterface (the as IHello line returns null); internally, there's a QueryInterface call across processes with said custom IID, the dispinterface is not registered under HKCR\Interfaces, so the interprocess COM machinery doesn't know how to marshal it. At least that's my theory.

A similar piece of logic works fine if the server is a native (C++) one. If the same C# piece is recompiled against .NET framework 4.72, it doesn't even get that far, the o as IHello; line returns null.

RunningObjectTable is a helper class around the ROT. For completeness' sake, here:

internal class RunningObjectTable
{
    #region API
    [DllImport("ole32.dll")]
    private static extern int CreateItemMoniker([MarshalAs(UnmanagedType.LPWStr)] string
               lpszDelim, [MarshalAs(UnmanagedType.LPWStr)] string lpszItem,
               out IMoniker ppmk);

    [DllImport("ole32.dll")]
    private static extern int GetRunningObjectTable(int reserved, out IRunningObjectTable prot);
    #endregion

    private IRunningObjectTable m_rot;

    public RunningObjectTable()
    {
        GetRunningObjectTable(0, out m_rot);
    }

    private IMoniker CreateItemMoniker(string s)
    {
        IMoniker mon;
        CreateItemMoniker("", s, out mon);
        return mon;
    }

    public int Register(string ItemName, object o)
    {
        return m_rot.Register(0, o, CreateItemMoniker(ItemName));
    }

    public void Unregister(int ROTCookie)
    {
        m_rot.Revoke(ROTCookie);
    }

    public object Get(string ItemName)
    {
        object o;
        m_rot.GetObject(CreateItemMoniker(ItemName), out o);
        return o;
    }
}

Can someone with access to .NET Core internals please tell me what's going on?

I have the exact same behavior between .NET 6 and .NET Framework, which is DISP_E_MEMBERNOTFOUND. I don't see how that could work if you don't register a typelib. If you replace your calling code by this: `dynamic o = new RunningObjectTable().Get("HelloTest");Console.WriteLine(o.Foo);` then it works in both .NET 6 and .NET Framework. — Simon Mourier, Dec 10 '21 at 09:00
My problem was the exception with DISP_E_MEMBERNOTFOUND during a cross-process method call. It's solved. In addition, I've figured out where does the wrong DISPID come from. — Seva Alekseyev, Dec 16 '21 at 21:21

Seva Alekseyev · Accepted Answer · 2021-12-13T14:19:07.863

Here's what is going on. The .NET object supports two dispinterfaces - one corresponding to IHello, another corresponding to Hello itself, and the latter is treated as the default one. I've confirmed that by adding an extra method Bar() to Hello, and checking the type in a native C++ client:

IUnknownPtr pUnk;
ROTGet(L"HelloTest", &pUnk);
IDispatchPtr pDisp(pUnk);
LPOLESTR Name = (LPOLESTR)L"Bar";
DISPID dispid;
hr = pDisp->GetIDsOfNames(IID_NULL, &Name, 1, 0, &dispid);

And I got S_OK and a valid, if bogus, DISPID. I then requested a DISPID for Foo in the same way, and got another bogus DISPID.

I've found two ways to fix that.

One, tell the framework that it should not implicitly generate a dispinterface for Hello. Annotate the class with [ClassInterface(ClassInterfaceType.None)], and it won't. The explicit check for the DISPID of Foo confirms that. The unmarshaled dispinterface in the client corresponds to IHello, and the methods work as expected.

Another approach, give IHello an identity (an IID) and make it marshalable. If I slap a custom GUID on that interface, and add a key with that GUID to HKCR\Interfaces, providing ProxyStubClsid32 equals to {00020420-0000-0000-C000-000000000046} (that's PSDispatch, the proxy/stub CLSID for IDispatch), the fragment also works.

One other way to tell COM that an IID corresponds to a dispinterface and should be marshaled as one is via implementing IStdMarshalInfo. I didn't try this.

One more note: the Hello class has to be declared public for this to work. If it's not, for some reason the as IHello returns null.

.NET 6 IDispatch client implementation crash

1 Answers1