5

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?

Community
  • 1
  • 1
AngryHacker
  • 59,598
  • 102
  • 325
  • 594

3 Answers3

1

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.

Sam Axe
  • 33,313
  • 9
  • 55
  • 89
1

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.

Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
  • I serialize with the Binary serializer and transmit via SOAP. Can you provide an example (even a theoretical one) where there would be an incompatibility? – AngryHacker Feb 10 '12 at 17:33
  • Not right off hand. If you are serializing your domain objects (and not stuff from the .NET Framework) and stick to primitives that existed since 1.x (shy away from nullable types, for example), I don't think you will have an issue, even with binary serialization. Basically, if you are passing state (basic objects with getters and setters on properties and not much else) and sticking to common primitives, you should be fine. – Gregory A Beamer Feb 10 '12 at 17:38
  • And, architecturally, you can revert to a SOAP based endpoint for your 1.x clients if you have broken outside of the "simple" mode. :-) ::: Gotta love the flexibility in WCF. – Gregory A Beamer Feb 10 '12 at 17:39
  • I think you misread my question. I don't have WCF or 1.x clients anywhere in the equation. Just standard Web Services connecting 3.5/4.0 pieces. – AngryHacker Feb 10 '12 at 18:26
1

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.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • The objects that I am running across the wire are isolated into a separate assembly (that is compiled to .NET 3.5). Both client and server have the exact copy of the assembly, so things like property changes are not a concern. Also, the objects are pure data transfer objects, e.g. there are no events or anything like that. Am I safe in that scenario? – AngryHacker Feb 10 '12 at 17:45
  • 1
    @AngryHacker I salute your good planning and forward thinking. That will actually isolate you from a world of pain here. With that setup, I would *expect* it to work. It would **surprise** me if that failed, but: occasionally surprises happen. – Marc Gravell Feb 10 '12 at 17:47