I have a ASP.NET web based application that allows the end user to export data to a flat file format. (essentially taking a point-in-time backup of their work)

At a later date they can re-upload (import) that data back into the web application.

The actual format of the backup is pretty trivial. An object graph is serialized using the WCF DataContractSerializer to xml, and then the resultant xml document is compressed. Importing, unzips it and deserializes the data.

There's one small problem I see with this approach. versioning... as time moves on and the data structures change (properties / child-collections are added/removed or renamed) then previously exported versions of a users data will no longer map to the object graph in the application.

Are there any specifici patterns or practices that address this issue? or any other reading material you could recommend.

  • Maybe have a data format version number in the file? Read that first, and use that to determine how to import the rest of the data. Apr 17, 2012 at 13:43
  • 3
    Data Contract Versioning and related SO question.
    – Oded
    Apr 17, 2012 at 13:53
  • @Oded: Maybe you should expand that into an answer? Apr 17, 2012 at 14:57
  • @FrustratedWithFormsDesigner - I don't really have enough for a proper answer. This is not an easy one...
    – Oded
    Apr 17, 2012 at 15:05

2 Answers 2


We have been using .NET Xml Serialization of pretty big graph of .NET objects for several years. We opted to take a very simple approach: keep the objects backward compatible at the code level. We generally only add new properties, and in the one case where we modified the datatype of a property, we created a new property with the modified datatype, and initialized it from the old data when user upgraded.

I think the one best practice we instituted, was that any new properties were always added as a full fledged property, and not just a class member variable. This enabled us to ensure that the code always initialized the new property to a helpful default value (instead of the blank/null value which it initializes to during deserialization.)

This has covered us for upgrades to the application over 5 years, with no bugs caused by deserializing old versions of the objects into newer version of the application. (once we adopted the approach above).


Have you considered adding a version to your export and then doing a version comparison during import?

If versions don't match, you can either fail import or warn the user that import is likely to fail, I don't see any other reasonable way of solving this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.