What fields and properties should be serialized?

Question

I do not think this is a duplicate. I read something, but did not find anything like it. It seems that the fields can be serialized in binary formats and in protobuf, but not in XML. I do not know about JSON.

I am considering replacing the standard .NET binary serializer with protobuf-net. The reason is to increase speed and get a smaller file size.

In NET Binary, I simply designated the classes as serializable and left them to that. Not good, I suspect.

With protobuf-net, I need to specify what is serialized with the [ProtoMember ()] attribute. My newbie test shows that private fields become serialized if they are marked as automatic properties.

I don’t want to change the class code definitions at all, because I still need to be able to deserialize the old stored data created by the NET serializer. I have a mixture:

• Private fields that are used inside the class
• Private fields whose value is set in the constructors
• Private fields that support fields for non-automatic properties
• Properties with top margins above
• Auto properties
• Properties without setters that return some calculation or value defined internally

and maybe some others. In other words, almost all types of fields and properties.

I assume that I need to save any value that represents the state of an object that cannot be created after deserialization from a file.

I believe that there would be no harm in saving each field and property, but that would just make the work slower and the file larger than it should be.

I think I can ignore private fields that are used only inside the class and are not set externally. I think I should persist in the fields that are set in the constructors. I am not sure about the support of the fields - is it better to preserve them or their public property? I have to save auto properties. I cannot save properties without settings, so I need all the fields / properties to be used in their calculations.

I am on the right track or missing a point.

Thanks in advance.

Answer 1

We cannot say what needs to be serialized. BinaryFormatter works on the basis of "all fields" (unless they are explicitly marked for serialization). You can use the same approach, but if you use automatically implemented properties (this is fine), then note that you cannot add attributes to the support field - unlike events like fields, the following is not valid C # :

 [field:ProtoMember(1)] // not valid public int X { get; set; } 

This means that your only reasonable choice is to decorate the property:

 [ProtoMember(1)] public int X { get; set; } 

Because if you change the automatically implemented property to a regular property, you will disrupt the BinaryFormatter deserialization, as the field name will be changed. However, there is nothing wrong with labeling fields or properties (or both of the same type) for serialization. Another consideration on some platforms is accessibility: a private field may not be available where, since a public field works fine. And, obviously, public fields are rather unusual.

So:

• decide what needs to be serialized (I can't tell you this)
• mark it for serialization
• nothing changes from an automatically implemented property to a regular property if you need BinaryFormatter to continue working (protobuf-net doesn't care if you change this)