WCF 服务的 Win32Exception @ ServiceHost.Open()

发布于 2024-08-07 20:02:25 字数 1656 浏览 6 评论 0原文

我正在为我正在编写的一系列广泛的 WCF 服务基础设施编写 BDD 规范。我注意到我编写的每个规范都涉及对 ServiceHost.Open() 的调用,该行需要花费 2 - 6 秒的时间来执行(随着我添加越来越多的规范,时间不断增长)。我注意到,当调用此方法时,会抛出 Win32Exception:

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

ServiceModel 配置如下:

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

注意:我已经配置了 Http.sys 并添加了 http://+:80/calculator/ 作为 http 命名空间排除,因此这不是问题的一部分。

此错误在 Windows 7 Ultimate 系统上最为严重。在 Vista Ultimate 系统上,它似乎不会对性能造成太大影响,但 ServiceHost.Open() 占据了执行过程中花费的大部分时间。我不明白为什么当 URL 是 localhost 时这是一个问题...我希望环回接口是最快的。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

孤独难免 2024-08-14 20:02:26

问题不在于 localhost 与 dns 名称...它与 WCF 调用 TranslateName() api 将服务的 UPN 身份从 SAM 兼容名称(即 DOMAIN\user)转换为规范名称,并抱怨它无法连接到中指定的域作为输入显示的 SAM 兼容名称。

不确定是什么原因导致此问题,但可能是您在 UPN 身份中指定了错误的域,或者您计算机的域注册出现问题,或者防火墙妨碍了操作。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文