If WCF Service side and Client side config is different?!

from stackoverflow  http://stackoverflow.com/questions/4879310/when-setting-up-a-wcf-client-and-server-how-synchronized-does-the-config-files

最近配置wcf服务,一直有个疑问,一直我们配置wcf服务端跟client端总是一致的,但是如果我们配置的不一样呢?在stackoverflow找到以下答案。其实这个没有说一定那边起作用,比如client的sendtimeout对应的是service端的receivetimeout,而且在client端有些配置是没有用的。这个还得细细琢磨。我擦。。。

In order to address your request in your last comment to my previous answer, I tried to come up with my approach to how I would create (and modify) server- and client-side config's for any given service. This is based on both theory I read (books, blogs), things I've learned in Juval Lowy's WCF Master Class, and quite a bit of practical experience with several large service implementation projects - this isn't available in one single place, on the web or in a book.... so here it goes:

I would start basically from scratch. Think about your service first:

  • what address does your service live at?
  • what binding(s) do you want to support?

Simplest scenario: single service, single endpoint, basicHttpBinding, all defaults

Service config:

<system.serviceModel>
   <services>
      <service name="YourNamespace.YourServiceClass">
         <endpoint name="Default"
             address="http://YourServer/SomeVirtualDirectory/YourService.svc"
             binding="basicHttpBinding"
             contract="YourNamespace.IYourServiceContract" />
      </service>
   </services>
</system.serviceModel>

Corresponding client config:

<system.serviceModel>
   <client name="Default">
      <endpoint name="Default"
          address="http://YourServer/SomeVirtualDirectory/YourService.svc"
          binding="basicHttpBinding"
          contract="YourClientProxyNamespace.IYourServiceContract" />
   </client>
</system.serviceModel>

Then only ever change something if you really must! And most of all: NEVER EVER let Visual Studio (Add Service Reference) or svcutil.exe screw up your config! Protect it like the apple of your eye!

Then: if e.g. your data transfer takes more time than the default timeout of 1 minute allows, change that one single setting on both the service side and the client side. Do this by defining a custom binding configuration and referencing that from your endpoints - but change only that - not more!Leave everything else as is, with default values. Don't ever change anything unless you absolutely must (and know what you're doing, and why you're doing it).

Mind you: the sendTimeout on the client (time allowed until the whole message has been sent) will correspond to the receiveTimeout on the server - the time allowed for the whole message to come in (see this excellent blog post and this MSDN forum thread for more information)

Service config:

 <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="ExtendedTimeout"
                 receiveTimeout="00:05:00" />
      </basicHttpBinding>
    </bindings>
    <services>
      <service name="YourNamespace.YourServiceClass">
        <endpoint name="Default"
            address="http://YourServer/SomeVirtualDirectory/YourService.svc"
            binding="basicHttpBinding"
            bindingConfiguration="ExtendedTimeout"
            contract="YourNamespace.IYourServiceContract" />
      </service>
    </services>
  </system.serviceModel>

Corresponding client config:

<system.serviceModel>
   <bindings>
      <basicHttpBinding>
         <binding name="ExtendedTimeout"
                  sendTimeout="00:05:00" />
      </basicHttpBinding>
   </bindings>
   <client name="Default">
      <endpoint name="Default"
          address="http://YourServer/SomeVirtualDirectory/YourService.svc"
          binding="basicHttpBinding"
          bindingConfiguration="ExtendedTimeout"
          contract="YourClientProxyNamespace.IYourServiceContract" />
   </client>
</system.serviceModel>

As you need other changes, like multiple endpoints on the service side, or local settings like bypassProxyOnLocal - adapt your config, do it carefully, step by step, manually, and consider your config an extremely essential part of your whole service - take care of it, put it in version control etc.

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

SignalR QuickStart

SignalR 是一个集成的客户端与服务器库,基于浏览器的客户端和基于 ASP.NET 的服务器组件可以借助它来进行双向多步对话。 换句话说,该对话可不受限制地...

2296
来自专栏刘望舒

Android PMS处理APK的复制

在上一篇文章Android包管理机制之PackageInstaller安装APK中,我们学习了PackageInstaller是如何安装APK的,最后会将APK...

2215
来自专栏木宛城主

ASP.NET MVC随想录——漫谈OWIN

什么是OWIN OWIN是Open Web Server Interface for .NET的首字母缩写,他的定义如下: OWIN在.NET Web Ser...

22811
来自专栏张善友的专栏

ASP.NET Web API RC版本新特性:Web API的帮助文档制作

InfoQ上有一篇文章是 使用IAPIExplorer列举ASP.NET Web API,文章针对的版本是ASP.NET Web API Beta版本写,IAP...

29310
来自专栏xingoo, 一个梦想做发明家的程序员

TCP客户机-服务器

1 僵尸进程 2 信号处理 信号: 1 由一进程发往另一进程 2 由内核发往某进程 僵尸状态: 父进程取回子进程的相关信息,进程的ID,终止状态,子进程的资源利...

2085
来自专栏WindCoder

微信小程序踩坑记-Java基于SSM下的post请求

最近在持续踩微信小程序的坑,canvas和WebSocket的暂时还没找到相关的解决方案,暂时先将post请求无法获取data参数的坑填上。直接附上解决方案,已...

1.1K1
来自专栏张善友的专栏

Windows 7上执行Cake 报错原因是Powershell 版本问题

在Windows 7 SP1 电脑上执行Cake的的例子 http://cakebuild.net/docs/tutorials/getting-started...

2279
来自专栏WindCoder

SpringBoot邂逅Shiro-前后端分离时的配置

本篇仅是记录集成的基础过程,至于shiro框架的基础概念和使用细节,可以自行查阅相关资料,本文不做讨论。

4.6K2
来自专栏逸鹏说道

我这么玩Web Api(一)

帮助页面或用户手册(Microsoft and Swashbuckle Help Page) 前言   你需要为客户编写Api调用手册?你需要测试你的Api接口...

3135
来自专栏冷冷

Spring Cloud Gateway 数据库存储路由信息的扩展方案

GatewayControllerEndpoint 基于actuate端点的默认实现,支持JVM 级别的动态路由,不能序列化存储

4522

扫码关注云+社区

领取腾讯云代金券