WCF服务接收大字节数组报maxArrayLength超限配置不生效问题

报错触发的核心原因是当前处理请求的XML读取器用的是默认配额配置，你写在web.config里的大配额配置没有实际生效，按以下顺序排查即可：

1. 先查客户端配置 #

• 这个配额是客户端、服务端双向校验的，绝大多数人改了服务端配置没用，都是漏了改客户端配置。如果调用服务的客户端项目没同步配置binding参数，请求在客户端序列化阶段就会抛这个错，根本发不到服务端。
• 客户端如果是用配置文件声明WCF调用，对应basicHttpsBinding节点下的readerQuotas、maxReceivedMessageSize、maxBufferSize参数要和服务端设成一致；如果是代码动态实例化客户端，不能直接new默认的BasicHttpsBinding就用，必须手动给实例的ReaderQuotas.MaxArrayLength、MaxReceivedMessageSize等属性赋值到你需要的大小。

2. 排查服务端配置加载失效问题 #

你当前的服务端配置有几个容易导致加载失败的点：

• 确认<service name="Bis.Edm.Service.EdmService">里的name值和你实际服务类的完全限定名完全一致，大小写、命名空间不能有任何偏差。只要name不匹配，WCF就不会加载你定义的service节点配置，自动回退到默认绑定，默认的MaxArrayLength就是16384。
• 你当前的<serviceBehaviors>下的<behavior>节点没有设置name属性，会作为全局默认behavior加载，建议临时把serviceDebug节点的includeExceptionDetailInFaults改成true，本地调用时看返回的错误详情，确认请求实际命中的绑定是不是你配置的basicHttpsBinding_Edm。

3. 排查自定义行为扩展覆盖配置 #

你配置了自定义终结点行为EdmBehaviorExtensionElement，如果这个扩展的实现代码里手动实例化了XmlDictionaryReaderQuotas用默认值，或者自定义了XML读取器的创建逻辑，会直接覆盖配置文件里的配额设置，强制使用默认16384的上限。

• 直接翻EdmBehaviorExtensionElement及关联的消息检查器、反序列化逻辑代码，看有没有硬编码创建读取器配额的逻辑，如果有，要么把MaxArrayLength同步设大，要么直接读取配置里的配额参数不要硬编码覆盖。

4. IIS托管场景兜底配置 #

如果你是IIS托管服务，先确认应用程序池的.NET版本选的是v4.8，和你配置的targetFramework一致，不要选低版本或者无托管代码模式。
可以额外加一个无name属性的默认绑定配置，强制所有未指定bindingConfiguration的basicHttpsBinding端点都使用大配额，避免因为配置匹配失败回退默认值，配置参考：

<basicHttpsBinding>
  <!-- 无name为全局默认绑定，所有未指定配置的端点自动应用 -->
  <binding closeTimeout="00:01:30" openTimeout="00:01:30" sendTimeout="00:01:30" receiveTimeout="00:01:30"
           messageEncoding="Mtom" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
    <security mode="Transport" />
  </binding>
  <!-- 原有命名绑定保留 -->
  <binding name="basicHttpsBinding_Edm" closeTimeout="00:01:30" openTimeout="00:01:30" sendTimeout="00:01:30" receiveTimeout="00:01:30"
           messageEncoding="Mtom" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
    <security mode="Transport" />
  </binding>
</basicHttpsBinding>

验证技巧：改完配置后重启对应IIS站点和应用池，先用小于16KB的数组请求确认服务正常，再发超限请求测试。如果还是报错，直接在服务端加WCF全局异常日志，记录异常抛出时当前绑定的实际配额值，就能快速定位是哪层逻辑覆盖了配置。

内容的提问来源于stack exchange，提问作者Yesimzhan Makishev