当前位置：文江博客话题详情

WCF 端点、baseAddressPrefixFilters、主机标头

发布于 2024-08-04 03:21:06 字数 334 浏览 4 评论 0原文

我在同一台机器上有两个网站。第一个（客户端）引用第二个站点（服务器）上的 WCF 服务。

如何设置服务参考地址？从本地计算机上的开发转移到组开发服务器时，如何更改服务的 URL？这些站点通过主机标头来区分，例如 http://dev.admin/... 和 http://dev.public/...

我感觉这可以使用多个端点来处理，但我'我对 WCF 很陌生，真的不知道我在这里做什么。

原文

分享到QQ

分享到微博

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

发布评论

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

稀香 2024-08-11 03:21:06

经过一番挫折后，我设法确定两个 web.config 文件（在客户端和服务器上，在本例中都是 Web 应用程序），必须更改以下部分：

客户端：

   <client>
      <endpoint 
        address="http://mysite.com:port/services/someservice.svc"
        binding="basicHttpBinding" 
        bindingConfiguration="BasicHttpBinding_ISomeService"
        contract="MyServices.ISomeService" 
        name="BasicHttpBinding_ISomeService" />

    </client>
  </system.serviceModel>

< 这里需要注意的是，所有三个相关部分（客户端端点地址、服务器baseAddressPrefixFilter 值和服务器端点地址）中的

 <system.serviceModel>
    <serviceHostingEnvironment>
      <baseAddressPrefixFilters>
        <add prefix="http://mysite.com:port/services"/>
      </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServices.SomeServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service behaviorConfiguration="MyServices.SomeServiceBehavior"
        name="MyServices.SomeService">
          <endpoint address="http://mysite.com:port/services/someservice.svc" 
                    name="endpoint.SomeService"
                    binding="basicHttpBinding" 
                    bindingConfiguration="" 
                    contract="MyServices.ISomeService"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>

主机地址必须匹配。

只要它们匹配，我就可以通过修改这些服务器在服务器之间切换。我仍然更喜欢一种根据服务器运行的机器来设置它的方法，但这目前有效。

WCF 展示次数
热门内容：持久对象。客户端代理对象（在添加服务引用时创建）维护与服务器上的服务的持久连接。客户端代理引用的服务实例在调用之间维护其状态，这可以简化方法签名并使客户端代理对象和整个服务对于某些应用程序更加有用。如果参数对象类型在公共库中声明，则可以在客户端和服务器之间共享它们，这意味着您不必创建两个非常相似的类或包装类来来回传递非原始数据结构。

事实并非如此：配置是一件非常痛苦的事情，文档很少，而且涉及太多。让它在测试/开发/登台/生产环境配置中工作，其中服务需要知道其位置，这是令人沮丧的。除了安全问题之外，我不相信让服务了解其域 URL（而不是其运行的相对路径）有任何重大好处。

也就是说，我将继续沿着 WCF 的道路前进，因为迄今为止的优势超过了令人头痛的问题。

After much frustration, I managed to determine that both web.config files (on the client and server, both of which are web apps in this case), the following sections have to be changed:

Client:

   <client>
      <endpoint 
        address="http://mysite.com:port/services/someservice.svc"
        binding="basicHttpBinding" 
        bindingConfiguration="BasicHttpBinding_ISomeService"
        contract="MyServices.ISomeService" 
        name="BasicHttpBinding_ISomeService" />

    </client>
  </system.serviceModel>

Server

 <system.serviceModel>
    <serviceHostingEnvironment>
      <baseAddressPrefixFilters>
        <add prefix="http://mysite.com:port/services"/>
      </baseAddressPrefixFilters>
    </serviceHostingEnvironment>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServices.SomeServiceBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service behaviorConfiguration="MyServices.SomeServiceBehavior"
        name="MyServices.SomeService">
          <endpoint address="http://mysite.com:port/services/someservice.svc" 
                    name="endpoint.SomeService"
                    binding="basicHttpBinding" 
                    bindingConfiguration="" 
                    contract="MyServices.ISomeService"/>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>

The thing to note here is that the host address in all three relevant sections (client endpoint address, server baseAddressPrefixFilter value, and server endpoint address) have to match.

I'm able to switch between servers by modifying these, as long as they match. I would still prefer a way to set this based on which machine the server is running on, but this works for the moment.

WCF Impressions
What's hot: persistent object. The client proxy object (created when you add a service reference) maintains a persistent connection to the service on the server. The service instance referenced by the client proxy maintains its state between calls, which can simplify method signatures and makes the client proxy object, and the service as a whole, much more useful for certain applications. Parameter object types can be shared between the client and server if they're declared in a common library, meaning that you don't have to create two very similar classes or wrapper classes to pass non-primitive data structures back and forth.

What's not: configuration is a royal pain, poorly documented, and far too involved. Getting this to work in a test/dev/staging/production environment configuration where the service neesd to be aware of its location is frustrating. I'm not convinced that making the service aware of its domain url (rather than, say, a relative path to whatever it's running on) has any significant benefit, security concerns aside.

That said, I'm continuing to go down the WCF path as the advantages thus-far outweigh the headaches.

回复收藏 0 原文