Persisted serialized objects & assembly version changes

[Guest]

If you serialize an object graph to persist it somewhere (e.g. a database) between application sessions, then you run into trouble if the serialized objects' existing field order or datatypes change, or if the object is moved from one assembly or namespace to another. Even if we're careful about making such changes, we need to serialize object graphs which may contain objects defined by the user, and users are sure to make incompatible changes to their objects

Assuming you change the asembly versions like you're supposed to when such incompatible changes occur, your application should be able to rehydrate the old objects because the old version of the assembly would be used. But how can you clone the object into its newer version to resave it, so it's not stuck forever in the old version? Somehow your code needs to be able to reference both versions of an object at the same time. Even if you can do that, the cloning process is sufficiently fussy that it seems to me you might as well just serialize your objects in your own simplified data format (XML or otherwise) that doesn't care about field count or order, or namespace, or assembly version. Then you can rehydrate the objects with your own code that can deal with datatype changes or missing fields and can use whatever the new version of the object is

Is it even worth trying to serialize objects for persistence then, using the standard binary or SOAP formatters?

 

[Guest]

I stumbled across SerializationBinder.BindToType(), which among other things, allows you to solve the versioning problem.

The .NET 1.1 Framework help for the BindToType method has an example that creates a Version1TypeToVersion2TypeBinder, inheriting from SerializationBinder, that allows you to substitute types during deserialization. By implementing ISerializable in your new version of the type, you use try/catch around the SerializationInfo.GetXXX() calls to deal with fields that are new or have changed datatype.