Win32Exception @ ServiceHost.Open () für den WCF-Dienst

Ich arbeite daran, BDD-Spezifikationen für eine breite Palette von WCF-Dienstinfrastrukturen zu schreiben, die ich schreibe. Ich habe bemerkt, dass jede Spezifikation, die ich schreibe und die einen Aufruf von ServiceHost.Open () beinhaltet, die Ausführung dieser Zeile gut 2 - 6 Sekunden dauert (die Zeit wächst, wenn ich immer mehr Spezifikationen hinzufüge). Ich habe festgestellt, dass beim Aufruf dieser Methode eine Win32Exception ausgelöst wird:

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

Die ServiceModel-Konfiguration lautet wie folgt:

<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>

Hinweis: Ich habe Http.sys konfiguriert und hinzugefügthttp: // +: 80 / rechner / als http-Namespace-Ausschluss, damit ist das nicht Teil des Problems.

Dieser Fehler ist auf einem Windows 7 Ultimate-System am schwerwiegendsten. Auf einem Vista Ultimate-System scheint dies weniger Leistungseinbußen zur Folge zu haben, wobei ServiceHost.Open () den größten Teil der für die Ausführung aufgewendeten Zeit ausmacht. Ich verstehe nicht, warum es überhaupt ein Problem ist, wenn die URLs localhost sind ... Ich würde erwarten, dass die Loopback-Schnittstelle die schnellste von allen ist.

Antworten auf die Frage(1)

Ihre Antwort auf die Frage