Rick,
I had a similar problem with SortedList, which can't be deserialized in 1.1
when serialized in 1.0. I got a comment from a MSFT employee which said that
they are aware of the problem and are working on it
(http://discuss.develop.com/archives/wa.exe?A2=ind0304C&L=DOTNET-CLR&P=R1489
&I=-3). What I did with my problem was: I manually edited the XML file which
resulted from the XmlSerializer to include the new property... This was the
cheapest solution in my case, but of course in no way a good one.

Regards,
Urs


-----Original Message-----
From: Rick Byers [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 11, 2003 11:59 PM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Serialization interop between .NET 1.0 and 1.1


Hi,

How are people dealing with changes in serialization format between .NET 1.0
and 1.1?  For example, the IPAddress class is now represented internally as
a Byte[] instead of an Int64 (why it was ever an Int64 is beyond me).  This
means that when it is serialized by the SoapFormatter or BinaryFormatter
(and probably the XmlSerializer), it can't be deserialized by a different
version of .NET.



I'm working on a distributed .NET computing platform (see
http://www.kinitos.com/), and we can't allways control the version of .NET
that is installed on a node, but we need to be able to continue to
communicate with it.  The problem is made worse by the fact that AppDomains
hosted in IE always run under the latest version of .NET that's installed -
so requiring .NET 1.0 to be installed doesn't solve the problem.



I had expected that Microsoft would keep the serialization format compatible
by implementing ISerializable for any class whose structure changes.  This
is what we have to do with our Serializable classes so that we're backwards
and forwards compatible.



I would imagine this is also a problem for people who are using
serialization for object persistence.  How can you upgrade your application
to .NET 1.1 while preserving application data?



I'm currently trying to work around the problem by using assembly rebinding
(to prevent .NET 1.0 from trying to load 1.1 assemblies if they are present)
and SerializationSurrogates to provide a common serialization format for
classes whose internal representation has changed.  I have no idea how many
such classes there are, so this could end up being a huge task.  I'm amazed
that this issue doesn't appear to have been discussed before.  Are we unique
in our serialization compatibility requirements?



Thanks,

    Rick

Reply via email to