Protobuf-net include specific member of non-serializable base class

Question

We are using protobuf-net (and love it!). We now have a protocontract-decorated child class derived from a parent base class, which IS NOT protocontract-decorated.

We are trying to get the child class to serialize/deserialize some of the parent class' fields.

public abstract class TableServiceEntity
{
    public virtual string PartitionKey { get; set; }
    public virtual string RowKey { get; set; }
    public DateTime Timestamp { get; set; }
}

[ProtoContract]
public class IndicatorStreamIndex : TableServiceEntity
{
    // protomember properties
}

How can we get IndicatorStreamIndex to serialize/deserialize PartitionKey, RowKey, and Timestamp?

Best, Mike

Answer 1

This can be configured pretty easily in v2, using RuntimeTypeModel to tweak the configuration at runtime:

// this should only be done once per AppDomain, usually at app startup
RuntimeTypeModel.Default.Add(typeof (IndicatorStreamIndex), true)
    .Add("PartitionKey", "RowKey", "Timestamp");

// then when needed:
var obj = new IndicatorStreamIndex
{
    RowKey = "abc",
    PartitionKey = "def",
    Timestamp = DateTime.Today
};
var clone = Serializer.DeepClone(obj);
Console.WriteLine(clone.RowKey); // "abc"
Console.WriteLine(clone.PartitionKey); // "def"
Console.WriteLine(clone.Timestamp); // 13/02/2012

Answer 2

First off - I think you have the technical basis to develop an excellent serializer. That said, I find various aspects of the ProtoBuf serialization so impractical that I cannot see myself using it in its current status.

Let me qualify - First off, with the explicit need for having the ProtoBuf attributes on a class for it to serialize forces a ProtoBuf deployment dependency; while one of the basic ideas behind serialization is that one could take the same classes, and swopping out serializer(s) if/when needed - meaning that the attributes and dll may be not be needed for different deployments.

2nd off - with ProtoBuf not by default recursing the inheritance tree makes it even more Protobuf specific - meaning more clutter in the code, more specific code dependency etc. This is a very obvious flaw in my opinion, as if one derives B from A, then one would naturally want the properties of A to be included when serializing B - without the custom code as shown in the thread above.

Thirdly - picture yourself that there is no need for the attributes... then you can also picture yourself serializing from objects e.g. object[] Parameters - which ProtoBuf cannot currently do. I guess (not being a serialization expert myself), that it may be as simple as putting the class and assembly as part of the the serialized object to resolve it remotely - keeping in mind that the same library must reside there as well. In other words, the ability to serialize any type / type hierarchy, without explicit attributes, based on the assumption that the same types by name and assembly will exist on the remote machine.

Marc, good luck with your implementation.

Gawie