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?
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.