Serialization has no way of inherently dealing with version issues. And
interfaces don't come in to it - serialization looks at your object's
internal state via reflection (or a similar mechanism - I don't know
that it uses reflection per se).

The best way to deal with this problem is to implement ISerializable and
implement the two methods (ISerializable::GetObjectData and a private
constructor) that are required for serialization.

It's really pretty easy - they give you a property bag, and you write
stuff to it as a series of name-value pairs. The tough part comes in
when you try to rectify the delta between the old object that was saved,
and the new one that you're trying to create. But since only you could
possibly know how to do this, the runtime leaves it up to you.

> -----Original Message-----
> From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED]] On Behalf Of Paul Currit
> Sent: Friday, July 05, 2002 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: [ADVANCED-DOTNET] Serialization and assembly version
redirection
>
> I am persisting objects to a database using the BinaryFormatter. When
> inserting new objects, I call BinaryFormatter.Serialize and store the
> object as a byte array in a database table. When getting an object out
of
> the table I use BinaryFormatter.Deserialize to convert the byte array
back
> into the object. If the version of the assembly containing the
> serializable type changes, can the serialized object in the database
be
> deserialized with the newer version. In other words, is there any way
to
> deserialize objects that were originally serialized under a different
> version number, as long as the type's interface hasn't changed? Is
this
> even an appropriate use of the BinaryFormatter, since it is typically
used
> for ephemeral objects and not persistence?
>
> I've tried using the <assemblyBinding> config section, but in my
tests,
> deserialization is ignoring the assembly version redirection.
>
> You can read messages from the Advanced DOTNET archive, unsubscribe
from
> Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.

You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced 
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to