简短的回答是,只需以这种方式将您的读者配额保持在您关注的绑定下(同时在绑定节点下增加 maxReceivedMessageSize),您可以放心,此错误不会出现在 production 上。它应该处理现实世界中任何大小的消息,但是您应该限制每个 wcf 设计所需的每个大小限制的数量。
<binding name="BindingForBiggerMessages"
maxReceivedMessageSize="2147483647">
<readerQuotas maxDepth="2147483647"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
还要确保您在 wcf 端的配置中所做的更改也在客户端应用程序端的配置中完成,否则将无法正常工作。
详细:---------------
这只是为了介绍如何在本地复制此问题,这实际上是不需要的,因为它在 wcf 社区中是众所周知的错误并且有针对它的有效解决方案,上面已经分享了
我觉得“Secret Squirrel”链接应该有助于解决这个问题,如果你还没有让它工作,那么请阅读这个,它会清楚地知道这些键在读者配额下是什么:
http://lucvknet.blogspot.com/2010/09/when-wcf-blows-whistle-part1.html
我想您需要关注的关键是MaxStringContentLength。实际上,您的生产应用程序的客户端正在向 wcf 发送消息,该消息在其中一个字段/属性中包含超过 8192 个字符(假设根据您的生产问题描述)。
在您的 wcf 配置(您在本地运行的生产副本)中查看,如果MaxStringContentLength在您的绑定下定义/配置(对于大型消息/对象来说是中断的绑定),如果未定义,则使用小于字符数的值定义它,您想测试消息中的给定字段(中断)。
因此,如果您希望您的 wcf 中断一个包含超过 8192 个字符的元素/字段的消息,则使其小于 8192,然后使用具有超过 8192 的字符串字段/成员的对象( wcf 方法的参数)调用 wcf字符,那么它应该打破。
注意:如果您在配置中看到MaxStringContentLength已定义为 8192,但您仍然没有遇到大消息/数据的问题,那么请确保消息具有一个设置了值的字段,使其超过了 MaxStringContentLength 设置的字符限制)
如果中断并且您收到与生产应用程序相同的错误,则只需将其配置为更高的值。
注意:如果您没有在 wcf 绑定中看到这些键定义,那么 wcf 将使用这些配额的默认值,因为它们不是您定义的,因此要复制问题首先要自己定义一个以覆盖任何默认设置。