none
Best approach for version tolerant serialization when new field allows null but has another default value. RRS feed

  • General discussion

  • I had asked a similar question:

    Thread Title Determining OptionalFieldAttribute.VersionAdded for field being deserialized 

    But it was inadvertently posted to the wrong forum (not a WCF question) and other than one reply I seemed to be having a conversation with myself.

    I would like to implement a robust serialization mechanism without having to do too much work and the BinaryFormatter seems to work well - except when the default value of a new variable is not null or zero.

    Take for example the case of adding a bool variable to an existing class class:

    [OptionalField(VersionAdded = 2)] 
    private bool doGood = true;
    

    When deserializing, if the version serialized was was of an earlier rev it will be de-serialized with a value of 'false' and to correct this in a method attributed with the Deserialized attribute it would be necessary to know this - hence the title of my original question.

    I have given up on discovering an easy way to determine the version of the saved class and am now asking - what is the recommended way to serialize a field such as this - with the least amount of hassle & maintenance.

    This must be a situation encountered by many developers so I assume that there are some recommendations or guidelines for how to do this.

    I proposed saving a dictionary with the full type name mapped to a version number but if was possible to force the BinaryFormatter to overwrite a static class variable that had already been initialized then that would appear to me as simpler and easier to maintain.

    • Changed type Fred BaoModerator Monday, February 9, 2015 10:47 AM The discussion is more suitable for this case
    Tuesday, January 13, 2015 1:34 AM

All replies

  • Hello,

    According to your another link, it seems that you are trying to use the OptionalFieldAttribute.VersionAdded Property, however, it seems that it fails. I am not sure which .NET Framework version you are using, for this property, even in 4.5 version, it is still not designed to be used in application as it says “this property is unused and is reserved”.

    >> This must be a situation encountered by many developers so I assume that there are some recommendations or guidelines for how to do this.

    Nor sure if it is good or recommended, my suggestion is that we could create a basic class which contains a property named version and let these types inherent it or add this property to these types and write the version value to this property and serialize it at the same time.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, January 14, 2015 2:59 AM
    Moderator
  • Thank you for the reply but I do not believe that it answers the issue "it seems that you are trying to use the OptionalFieldAttribute.VersionAdded Property, however, it seems that it fails" - no it does not (at least for fields that have null or zero as their default value).

    Although I have seen various posts indicating that there are issues with binary serialization - they all seem to be fairly old and that has not been my experience - indeed version tolerant serialization has allowed me to serialize past (and future) versions quite well with virtually no effort on my part.

    In my first post within the linked thread I attempted to point out that the documentation for for the VerionAdded property was wrong - or at least in conflict with the suggested 'best practices' by stating: "Incidentally in the best practices section of Version Tolerant Serialization it states: "Always set the VersionAdded property on the OptionalFieldAttribute attribute correctly." but the documentation for OptionalFieldAttribute version added states: "This property is unused and is reserved." this may have been correct for .NET 2.0 but...". Incidentally I am using .NET 4.5.51650 which as far as I am aware is still out of sync with the symbol libraries so that it is not possible to step in to the serialization code. Having issues with the VersionAdded property when using .NET 2.0 seems quite reasonable as it was added after that.

    My problem with the serialization mechanism is that it only works for fields with null or zero as the default and this appears to me as a serious omission because the version serialized does appear to be stored in the file - it just seems unobtainable.

    As for "we could create a basic class which contains a property named version and let these types inherent it or add this property to these types and write the version value to this property and serialize it at the same time" - this is essentially what I proposed in the other thread, except that it should apply to each class that uses the OptionalFieldAttribute with the VersionAdded property when the field value is not null or zero - not just in a base class - and it should be static unless there is a desire to store different versions of the same class in the serialized file (not something I plan to do).

    But this approach is inherently unsatisfactory as the serialization process already seems to do this - we are just not provided with the value of the version of the class that was serialized - why?

    Friday, January 30, 2015 7:47 PM