As described in this post, we can use ProtoInclude attribute to manage class hierarchy serialization. And if we use just protobuf-net, it works quite fine both directions. But problem occurs when we try to deserialize messages, serialized by "external" legacy Protocol Buffers implementations, ex. Java, etc.
As mentioned in that post above, Protobuf-net recognizes class hierarchy by "reversed" bytes sequences, when child class fields serialized before parent's. But legacy code serialize them in "proper" order and protobuf-net throws an "Unable to cast object of type 'A' to type 'B'." exception during deserialization. In opposite direction it works fine, legacy code can deserialize "hierarchic" messages produced by protobuf-net library.
I can not affect byte serialization order on opposite side of the pipe. How can I correctly deserialize this type of messages on .NET protobuf-net side?
Update: code examples
On our end of the line we have original protobuf-net hierarchic classes:
[ProtoContract, ProtoInclude(10, typeof(B))]
public class A
{
[ProtoMember(1)]
public int Age;
}
public class B : A
{
[ProtoMember(2)]
public int Balls;
}
On the other end of the line classes are generated using .proto file:
message B {
optional int32 balls = 2;
}
message A {
optional int32 age = 1;
optional B b = 10;
}
Generated classes example, we could use protobuf-net generator to create them for .NET:
[ProtoContract]
public class A_generated
{
[ProtoMember(1)]
public int Age;
[ProtoMember(10)]
public B b;
}
[ProtoContract]
public class B_generated
{
[ProtoMember(2)]
public int Balls;
}
So now, let's serialize and deserialize class B:
- Serialize and deserialize back original classes - OK
- Serialize and deserialize back generated classes - OK
- Serialize original and deserialize as generated - OK
- Serialize generated and deserialize as original - FAIL, "Unable to cast object of type 'A' to type 'B'." exception
I've investigated resulting bytes and discovered a difference - bytes order.
Example: let Age=10 and Balls=23. Then:
- original B serialized: [82, 2, 16, 23, 8, 10], could be deserialized using both as original as generated classes;
- generated B serialized: [8, 10, 82, 2, 16, 23], can NOT be deserialized using protobuf-net original classes above.
I hope now it's clear enough, and wish to get positive answer: yes, there is a way to use ProtoInclude and deserialize generic classes.
