WCF MTOM/XOP客户端反序列化错误

Question

这是我已经回答过的那些“问题”中的一个，但我发布的b/c基于一周的谷歌搜索，似乎几乎没有任何信息。

WCF MTOM编码的BasicHttpBinding客户端到外部/第三部分，非.NETWeb服务阻塞MTOM响应的XOP处理-基本上MTOM编码器似乎期望在二进制元素中的base64有效负载，但运行到...指令，并且无法将SOAP/XML反序列化为运行时对象，因此在此问题的标题中抛出错误。

错误:应为命名空间'http://mynamespace‘中的结束元素'MyBinaryData’。在命名空间'http://www.w3.org/2004/08/xop/‘中找到元素'xop:Include’

正如前面提到的，在这个主题上没有太多的东西，我猜b/c MS写的大多数WCF文档都是基于服务开发的，而不是那么多的客户端(虽然也有一些，公平地说)。

我不打算深入到我将要回答我自己的问题的最基本的初始设置b/c，但我会在回答之前说，这更类似于WCF MTOM的默认配置。

此外，我知道WCF是旧的，无聊的，不再由微软积极开发，但它仍然得到支持，它有很多用途。实际上，我没有太多的选择，必须找到一种方法来实现这一点。这就是为什么我要将我的发现分享给任何需要处理这种头痛问题的人。

Answer 1

TL;DR:检查http头部，看看服务响应是否对您是"Transfer-Encoding: chunked“(流式传输)，如果是，请在绑定配置中使用transferMode="StreamedResponse”。

因此，在谷歌了几天没有任何帮助后，我启动了Fiddler来捕获http流量-这需要你的WCF基本http绑定配置来代理Fiddler (我想是默认的http://localhost:8888)，根据你的目标服务驻留的位置，你可能需要也可能不需要配置Fiddler的网关设置(企业代理等)。

这使我能够看到客户端与其服务之间发送的原始文本；所有有效负载都可以正常接收，这意味着，在我的示例中，来自服务的MTOM/XOP响应被完全传输，而WCF运行时没有正确解释响应。我看到的另一个关键是，Transfer-Encoding http报头是“分块的”，并且没有Content-Length报头……这意味着服务正在流式传输响应，而不是缓冲的响应。现在需要注意一点:MS的WCF MTOM文档中有一个说明，说明在绑定配置中应该始终使用"Buffered“作为transferMode……但是没有提到这实际上只适用于服务，而不一定适用于客户端！

因此，我很自然地进入我的配置文件，找到system.serviceModel >> bindings >> basicHttpBinding集合，找到我特定的绑定配置，并将transferMode=设置为“StreamedResponse”(因为第三方服务正在将我的响应传输回我的客户端)。