ASP.NET Core 3.1迁移后XmlSerializerFormatters不兼容根节点xmlns的XML请求

问题核心根因 #

这个差异本质和.XmlSerializerFormatters的配置参数无关，根源是两个版本Svcutil工具生成的WCF代理类的XML序列化元数据存在不兼容差异：

• 旧版本preview工具生成ConnectedServiceRequestX类时，会在类级别通过[XmlRoot(Namespace = "http://somename.com/api/01")]声明整个类对应的默认XML命名空间，子元素会自动继承该命名空间，因此只要根节点带上xmlns声明，所有子元素即使不重复写xmlns也能被正常解析。
• 新版本2.0.2工具生成类时，移除了类级别的命名空间声明，反而给每个公开属性单独打了[XmlElement(Namespace = "http://somename.com/api/01")]标记。这种标记下XmlSerializer会认为每个属性的命名空间是独立的，不继承根节点的默认xmlns，必须每个子元素单独携带命名空间声明才能匹配成功。
  这也是为什么旧应用能兼容根节点带xmlns的格式，新应用就抛出解析异常的核心原因。

落地解决办法 #

方法1：修正自动生成类的序列化元数据（修复最直接） #

打开Reference.cs中对应ConnectedServiceRequestX类的定义，对照旧版本的生成结果调整特性标记：

• 移除每个公开属性上单独标注的XmlElement(Namespace = "http://somename.com/api/01")里的Namespace属性
• 在类级别补上[XmlRoot(Namespace = "http://somename.com/api/01")]标记
  调整完成后，两种XML格式都能被正常反序列化。
  注意：每次更新WCF连接服务都会重新生成Reference.cs文件，建议把这套元数据调整逻辑集成到生成流程的后处理步骤里，避免每次重新生成都需要手动修改。

方法2：自定义输入流预处理（零侵入生成代码） #

如果不想改动自动生成的代理类文件，可以通过自定义InputFormatter的方式，在请求进入反序列化逻辑之前，自动处理XML的命名空间：

1. 继承框架内置的XmlSerializerInputFormatter，重写ReadRequestBodyAsync方法
2. 读取原始请求的XML流，加载为XDocument对象
3. 提取根节点上声明的默认xmlns，遍历所有子元素，移除子元素上重复声明的相同命名空间属性，让子元素继承根节点的命名空间
4. 将处理后的XML流传给基类的原生反序列化逻辑
   这种方式不需要改动任何自动生成的代码，对现有业务逻辑的侵入性最低。

关于格式化器配置的猜想回应 #

你提到希望通过给.XmlSerializerFormatters()加配置来适配旧格式，实际上框架层面目前没有提供对应的直接开关——因为XmlSerializer的元素匹配规则完全由类上标注的序列化特性决定，不会主动跨元素继承命名空间，纯靠配置参数无法绕过生成类元数据不匹配的问题。 #

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