WCF:一个棘手的问题

前言

在做即时通信项目时,手上另一个项目的颠簸,即时通信项目一直是改改停停的,一些改动比较小,没有即时的签入,然后一段时间本地的项目代码与源代码存在不少区别,在这种情况下,因为新的需求添加,需要给WCF服务添加新的方法,出现了一个浪费我很长时间的问题。

 

问题

遇到的问题:
服务器未提供有意义的回复;这可能是由协定不匹配、会话过早关闭或内部服务器错误引起的。

这个问题,之前有遇到过,并按照网上的解决办法进行了修改,没想到又出现了,之前的解决办法如下:
可能原因:
1、WCF中不允许在协议中定义一个类型而传输其子类型. 除非在该类型上定义了[KnownType(typeof(子类型))]
2、WCF传输List<object>时序列化问题
WCF传输List集合时,在序列化时是有大小限制的,默认的可序列化的集合长度是65536,如果List的大小超出这个值就需要更改了配置了,在服务器端的behavior配置中增加一行配置:

<behavior name="WCFService.Behavior">
          <serviceMetadata/>
          <serviceDebug includeExceptionDetailInFaults="false" />
          <dataContractSerializer maxItemsInObjectGraph="6553600"/>
</behavior>

并且在对应的binding配置中添加readerQuotas节点配置:

    <binding name="BasicWsHttpBinding">
          <reliableSession enabled="true" />
          <security mode="None">
            <transport clientCredentialType="None" />
            <message clientCredentialType="None" />
          </security>
          <readerQuotas maxDepth="32" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
    </binding>

 

解决方法

再次遇到这个问题,心里一阵恐慌,会话过早关闭与内部服务器错误是不可能的,只能是协定不匹配导致,但是我反复排查确认,协定也是正确的,花费大量时间后,依然没有解决此问题,到最后没办法,让同事获取源代码的最新版本,然后把我添加的新方法,让他也添加一遍,清理解决方案后,重新生成,运行后正常启动。这就无奈了,想前想后,只能把问题归咎于没有及时签入代码上了,可能版本上会存在一些问题。

 

经验教训

项目中的代码要及时签入,改动某些地方后,重新运行程序测试没问题,就签入好了。反正有变更集,出问题还可以在还原。另外,遇到一些棘手问题,如果实在没有思路,不妨把代码还原一下,然后把更改的内容在重新添加一遍,或许问题就解决了。

 

posted @ 2018-11-15 16:02 流浪阿丁 阅读(...) 评论(...) 编辑 收藏