Win32Exception @ ServiceHost.Open() for WCF servic

Question

I am working on writing BDD specifications for a broad set of WCF service infrastructure I am writing. I have noticed that each specification I write that involves a call to ServiceHost.Open(), that line takes a good 2 - 6 seconds to execute (the time keeps growing as I add more and more specs). I noticed that when this method is called, a Win32Exception is thrown:

Win32Exception occurred
Message: The specified domain either does not exist or could not be contacted.
Stack Trace: at System.ServiceModel.UpnEndpointIdentity.GetUpnFromDownlevelName(String downlevelName)
NativeErrorCode: 1355
ErrorCode: -2147467259

The ServiceModel configuration is as follows:

<system.serviceModel>
  <services>
    <service name="TestServices.Calculator" behaviorConfiguration="default">
      <endpoint
        name="calculator"
        address=""
        binding="wsHttpBinding"
        contract="TestServiceContracts.ICalculator" />
      <endpoint
        address="mex"
        binding="mexHttpBinding"
        contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="http://localhost/calculator" />
        </baseAddresses>
      </host>
    </service>
  </services>

  <behaviors>
    <serviceBehaviors>
      <behavior name="default" >
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Note: I have configured Http.sys and added http://+:80/calculator/ as an http namespace exclusion, so that is not part of the problem.

This error is most severe on a Windows 7 Ultimate system. On a Vista Ultimate system, it does not seem to cause as much of a performance hit, however ServiceHost.Open() is the vast bulk of the time spent in execution. I don't understand why it is an issue at all when the URL's are localhost...I would expect the loopback interface to be the fastest of all.

Answer 1

The problem isn't with localhost vs dns name... it's related to WCF calling the TranslateName() api to convert the UPN identity of the service from a SAM-compatible name (i.e DOMAIN\user) to a canonical name, and complaining that it cannot connect to the domain specified in the SAM-Compatible name presented as input.

Not sure what might be causing this, but it could be that you're somehow specifying a wrong domain in your UPN identity, or there's something wrong with your machine's domain registration, or the firewall is getting in the way.