3

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.

jrista
  • 32,447
  • 15
  • 90
  • 130

1 Answers1

4

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.

tomasr
  • 13,683
  • 3
  • 38
  • 30
  • What if the machine is not on a domain at all? All of the systems I am testing on are simply a part of the default WORKGROUP work group. – jrista Oct 09 '09 at 14:13
  • Could it be that DNS isn't resolving your machine name to the local IP, but instead is resolving to something else so that the OS is interpreting as a domain name? – tomasr Oct 09 '09 at 15:09
  • I have not actually set the element. I am not sure what it defaults to when it is not explicitly set. I will see what I can find. – jrista Oct 09 '09 at 15:38
  • This did indeed turn out to be the issue. Joining to the domain on my work system greatly reduced the startup time. Thanks! – jrista Oct 14 '09 at 20:38