Andy McMullan

In a previous post I described how to host a COM server in a managed process using RegistrationServices.RegisterTypeForComClients.  I’ve been using this approach successfully for a while, but today I hit a snag.   I changed my C# server process from 32-bit to 64-bit, and immediately my 32-bit C++ client could no longer connect.

In theory it shouldn’t matter to the client whether the server is 32-bit or 64-bit – everything is out-of-process so there is no compatibility issue.   But I could see that COM was refusing to allow my client to connect to the running 64-bit server process, and instead was trying to launch a new server process (which was failing because I don’t allow that).

I have seen this type of problem many times before with COM, and it’s almost always due to security configuration – specifically the ‘run as’ configuration of the server.   So I spent a lot of time investigating that, but it turned out to be something much simpler.  Since Windows 2003 SP1, COM has a rule on x64 that if a 32-bit client CoCreates an out-of-proc server, COM will try to connect to a 32-bit server.  If the client is 64-bit, COM will try to connect to a 64-bit server.  So in my case, COM could see that the 64-bit server was running, but because the client was 32-bit it decided to launch a new (hopefully 32-bit) server process to service the request.

Fortunately there are two easy ways around the problem.  The first option is to modify the client to specify  CLSCTX_ACTIVATE_64_BIT_SERVER in the CoCreateInstance call.  The other (probably better) option is to add a PreferredServerBitness flag to the AppID registry entry for the server.

CLSCTX_ACTIVATE_64_BIT_SERVER is described here, and PreferredServerBitness here.

For my current project I have some old unmanaged C++ code that needs to talk to a new .NET server, remotely.   The channel needs to be fast and secure.   There are a lot of options, but I’ve narrowed it down to two:

1. WWSAPI for the C++ client, WCF for the .NET server, using NetTcpBinding.  (See here for details.)
2. DCOM

Option 1 was the strong favourite until Microsoft decided to play silly buggers with the redistribution rights for WWSAPI, so I’ve been forced to investigate option 2.

COM interop through loading .NET components into an unmanaged process is well documented and generally works fine, but accessing a .NET server remotely via (D)COM is not so well documented, and indeed it’s not even clear if it’s supported by Microsoft.   But it does seem to work, and it’s surprisingly simple once you discover the RegisterTypeForComClients method on the RegistrationServices class.   This is basically a wrapper for COM’s CoRegisterClassObject.

Here’s the C# server code:

[ComVisible(true)]
public interface ICalculator
{
    int Add(int x, int y);
}

[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
public class Calculator : ICalculator
{
    public int Add(int x, int y) { return x + y; }
}

class Program
{
    [MTAThread]
    static void Main(string[] args)
    {
        var regServices = new RegistrationServices();

        int cookie = regServices.RegisterTypeForComClients(
            typeof(Calculator),
            RegistrationClassContext.LocalServer | RegistrationClassContext.RemoteServer,
            RegistrationConnectionType.MultipleUse);

        Console.WriteLine("Ready"); Console.ReadKey();

        regServices.UnregisterTypeForComClients(cookie);
    }
}

and the C++ client code:

#import "dcomserver.tlb" no_namespace raw_interfaces_only

int _tmain(int argc, _TCHAR* argv[])
{
    CoInitializeEx(0, COINIT_MULTITHREADED);

    {
        CComPtr<ICalculator> spCalc;
        spCalc.CoCreateInstance(__uuidof(Calculator), 0, CLSCTX_LOCAL_SERVER);

        long result = 0;
        spCalc->Add(10, 20, &result);

        cout << result << endl;
    }

    CoUninitialize();
    return 0;
}

(The simplest way to generate the tlb file to #import is to run regasm /tlb DcomServer.exe)

There may well be some gotchas with this approach – I haven’t tested it thoroughly yet – but it seems a promising option if the WWSAPI licensing issues can’t be sorted out.