Cook Computing

DCOM String Binding Problem Explained

February 6, 2003 Written by Charles Cook

I posted a few weeks ago about a DCOM string binding problem with Windows 2000. The root cause of the problem was that from Windows 2000 onwards the list of string bindings returned by a DCOM server have a fully qualified domain name as the first entry:


It turns out that that there is no way round this. I posted to one of the MSDN managed newsgroups yesterday and Santhosh Pillai helpfully replied:

There is no way you can avoid getting FQDN in the marshaled interface pointer. The FQDN present in the marshaled interface pointer is a huge help when DCOM server is behind a NAT-based firewall.

You may, however, add a host file (system32\drivers\etc\hosts) entry in*every client* box which points to the correct IP address.

Interesting. Although the solution he suggests is not really suitable for our situation, its useful to know where we stand.

This sort of problem has been very frustrating when working with DCOM. Fortunately there has been a huge paradigm shift in .NET where everything is configurable and even replaceable, for example you can install and configure your own Remoting channels. The string binding problem will cause extra work for us because DCOM is a black box and we can't configure away the problem. The .NET paradigm of openness is very welcome.