Deserialization versions

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

Serialization is great except that it does not accommodate version changes
(adding a property to a class renders it unable to deserialize because an
exception is thrown).

I think I understand the philosophy underlying the choice of the
architecture used by MS in thier decsion to enable version change only by
implementation of ISerializable. However, I want to see the equivalent of
an 'On Error Resume Next' (aka 'go for it') in the deserialization process,
I want to be able to override the BinaryFormatter to hydrate everything it
can without crashing.

It's utterly practical, no? Saves code and bugs introduced in the ugly (my
opinion) ISerializable implementation.

Dan
 
We use a static helper, something like this:

public class Serializer
{
static DataIn(objecttype, info, context)
{
}
static DataOut(object, info, context)
{
}
}

Each class that implements ISerializable simple has 1 line implementations
which call a helper in Serializer.
This way, all our classes are very tolerant of change, far more so than they
were in MFC.

"Programming .NET Components" (Juval Lowy) has quite a good chapter on a
similar concept.

Rob.
 
If I understand you correctly, you are suggesting the DataIn() and DataOut()
methods use reflection to populate the graphs. Something like:

foreach(System.Reflection.PropertyInfo p in
objecttype.GetType().GetProperties)
{
p.SetValue(objecttype, info.GetObject(p.Name));
}

This is a guess, I haven't actually tried it, for example, GetObject must
also be coerced to the correct value type. Am I wrong?
 
Back
Top