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?
