com64-bitcom-interopvb6-migrationmidl

64-bit managed process: out-of-proc 32-bit COM server non-default interfaces not available

I am migrating an Excel add-in originally written in VB6 to managed code and 64-bit Excel. The add-in interoperates with some legacy 32-bit COM DLL servers through COM surrogates, and an issue has been encountered where only methods and properties in the coclasses' respective default interfaces are available at runtime. Attempts to call methods and properties in any other interfaces exposed by the components results in System.MissingMethodExceptions.

The non-default interfaces are available when the migrated add-in is used with 32-bit Excel and the servers run in-process.

Is there anything that can be done to make the non-default interfaces available to the add-in in 64-bit mode?

Solution

  • The solution was to use type library marshaling (also known as universal marshaling), using the system-provided marshaling engine in oleaut32.dll. The universal marshaler can be used with any custom interface, provided that the parameters are variant-compatible.

    To use the universal marshaler for an interface, the interface is tagged with oleautomation, as in this sample interface:

    [
    object,
    oleautomation, 
    uuid(23D4EC0B-96DA-4D18-82BD-40E3AA0483FD),
    version(1.0),
    dual,
    helpstring("Description of ICustomInterface1"),
    pointer_default(unique)
]
interface ICustomInterface1 : IDispatch
{
    // Methods and properties …
}

    Universal marshaling also requires the following Registry entries:

    With this type information, the universal marshaler creates a proxy-stub at runtime, eliminating the need for a custom proxy-stub DLL.

    In our case, given that the components were ATL-based, the Registry entries were created automatically once the interfaces were tagged with ‘oleautomation’ and the components rebuilt. For non-ATL projects, this can be done programmatically with the Win32 API’s LoadTypeEx() (which I haven't tried).

    Once this was done, non-default interfaces of our ATL-based components became available out-of-process to our migrated-to-VB.NET Excel COM add-in.

    All this is detailed in Chapter 5 of "Developer's Workshop to COM and ATL 3.0."