对象可以跨不同框架版本进行序列化/反序列化吗？
我需要使用 BinaryFormatter 和 .NET 4.0 序列化一个对象，并将其通过网络（通过 SOAP 作为字节数组）发送到在 .NET 3.5 下运行的 Web 服务。反之亦然。我已经测试过这个场景，它似乎工作得很好。
关于这种情况，有一个老问题，即谈论 .NET 1.x 到 2.0，这并没有让我对该方法充满信心。
所以它在我的测试工具中有效，但我无法测试对象的所有可能的变化，所以我需要一些理论基础。
通常，对象可以跨不同框架版本进行序列化/反序列化吗？这是一个可接受的场景还是对我的案例有效的黑客？
I need to serialize an object using the BinaryFormatter with .NET 4.0 and send it across the wire (via SOAP as a byte array) to a web service running under .NET 3.5. And vice versa. I've tested this scenario, and it seems to work fine.
There is one old question regarding this scenario on SO, that talks about .NET 1.x to 2.0, which did not leave me with a lot of confidence about the approach.
So it works in my test harness, but I can't test every possible variation of the object, so I need some theoretical underpinnings.
As a rule, can objects serialize/deserialize across different framework versions? Is this an accepted scenario or a hack that worked in my case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果“二进制”指的是 BinaryFormatter，那么它在版本之间已经非常不宽容，因为它严格依赖于类型元数据（除非您非常努力地使用自定义绑定）。因此，只有当两端使用完全相同相同的实现时，它才是严格可靠的。即使将属性更改为自动实现的属性或从自动实现的属性更改属性也是一项重大更改。
这不是“二进制”的失败，而是 BinaryFormatter 的一个功能。其他二进制序列化器没有这个问题。例如，protobuf-net 在操作系统之间、框架之间等工作 - 因为格式 a: 不关心您的特定类型，而 b: 固定为已发布的规范。
如果您当前为此使用 BinaryFormatter：那么 IMO 是的，您应该显式测试每个 API。由于任何类型都可能更改实现细节。不幸的是，由于 BF 习惯于提取意外数据（通过事件等），因此即使这也不一定足以验证实际使用情况。
If by "binary" you mean BinaryFormatter, then it is already hugely intolerant between versions, since it is strictly tied to type metadata (unless you work really hard with custom bindings). As such, it is only strictly reliable when both ends are using exactly the same implementations. Even changing a property to/from an automatically implemented property is a breaking change.
This isn't a failing of "binary", but a feature of BinaryFormatter. Other binary serializers don't have this issue. For example, protobuf-net works between OS, between frameworks, etc - since the format a: doesn't care about your specific types, and b: is fixed to a published spec.
If you are using BinaryFormatter for this currently: then IMO yes, you should explicitly test every API. Since any type could change an implementation detail. And unfortunately since BF has a habit of pulling in unexpected data (via events, etc), even this isn't necessarily enough to validate the real usage.
如果序列化格式是 XML (SOAP) 或 JSON，那么它绝对可以正常工作。我不确定二进制序列化对象会如何反应。
If the serialization format is XML (SOAP) or JSON it should absolutely work no problem. I am unsure of how a binary serialized object would react.
序列化的最大问题是当您拥有不存在的原语时。天啊，在本机代码中访问某些类型时存在问题，因此这不是服务中发现的唯一问题（假设）。
作为“规则”，您可以跨框架版本进行序列化，甚至可以序列化到用 Java、Delphi 和 COBOL 编写的客户端（提供具有 Web 服务功能的版本 - 并且前提是您已通过服务端点适当地公开了序列化对象）。
我试图思考 .NET 中是否存在 1.x 中不存在的原语，因为它们会出现问题。与您可能尝试序列化的任何新框架对象一样。使用 2.0 的危险要小得多（也许不存在？）
序列化越“开放”（即 JSON、SOAP 等标准 - 简化：JSON 或 XML，至少在大多数情况下），可能性就越小你会有问题。而且，如果您遇到问题，您可以围绕 automagic 代理等进行编码。当您转向二进制时，在 4.0 中使用 WCF 序列化的对象与远程客户端之间可能会存在一些不兼容性。
The biggest issue with serialization is when you have primitives that do not exist. Hell, the problem exists when going to certain types in native code, so it is not a unique problem found in services (assumption).
As a "rule", you can serialize across framework versions and even to clients written in Java, Delphi and COBOL (provided a version with web service ability - and provided you have exposed the serialized objects appropriately through a service endpoint).
I am trying to think if there are any primitives in .NET that were not present in 1.x, as they would be problematic. As would any new framework objects you might try to serialize. You have a lot less danger with 2.0 (perhaps non-existent?)
The more "open" your serialization is (ie, standards like JSON, SOAP, etc - simplified: JSON or XML, at least in most cases), the less likely you are to have issues. And, if you have issues, you can code around the automagic proxies, etc. As you move towards binary, you can have some incompatibility between an object serialized in 4.0 with WCF and a Remoting client.