Deserialization versions

[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

[Robert Hooker]

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.
"Dan" <mt*******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

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

[Dan]

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?


"Robert Hooker" <rh*****@rhooker.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

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.
"Dan" <mt*******@hotmail.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

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