version compatibility when serializing and deserializing

[Tony Johansson]

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of your
application, Specilically if you add a member to a custom class and attempt
to deserialize an object that lacks that member, the runtime will throw an
exeption. In other words if you add member to a class in version 3.1 of your
application it vill not be able to deserialize an object created bt version
3.0 of your application."

I seems to me that the text saying "Specilically if you add a member to a
custom class and attempt to deserialize an object that lacks that member,
the runtime will throw an exeption" will not throw any exception for me.I
tried just this first I serialized this class below without having the name
included in the ShoppingCartItem class.
I then I added this name to the class definition and then I deserialized the
file with the serialized object and I didn't get any exception. The name
field was null. So as a summary is the text in the book from Microsoft Press
wrong ?

[Serializable]
public class ShoppingCartItem
{
public int productId = 13;
public decimal price = 10.50M;
public int qty = 20;
//string name = "test";
}

//Tony

 

[Family Tree Mike]

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of your
application, Specilically if you add a member to a custom class and attempt
to deserialize an object that lacks that member, the runtime will throw an
exeption. In other words if you add member to a class in version 3.1 of your
application it vill not be able to deserialize an object created bt version
3.0 of your application."

I seems to me that the text saying "Specilically if you add a member to a
custom class and attempt to deserialize an object that lacks that member,
the runtime will throw an exeption" will not throw any exception for me.I
tried just this first I serialized this class below without having the name
included in the ShoppingCartItem class.
I then I added this name to the class definition and then I deserialized the
file with the serialized object and I didn't get any exception. The name
field was null. So as a summary is the text in the book from Microsoft Press
wrong ?

[Serializable]
public class ShoppingCartItem
{
public int productId = 13;
public decimal price = 10.50M;
public int qty = 20;
//string name = "test";
}

//Tony

Your test was done in the wrong order. You would need to serialize an
instance with the name field present. This represents the version 3.1
concept. Now deserialize it to a class without the name field defined,
representing the 3.0 version. You will get the exception.

 

[Mr. Arnold]

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of your
application,

No, I don't think so. An object that has been serialized is XML and XML
is string. XML object flies around on the internet between between Web
client and Web service with the client and service using different
versions of .Net or the client can be .NET and the service is java.

Specilically if you add a member to a custom class and attempt
to deserialize an object that lacks that member, the runtime will throw an
exeption. In other words if you add member to a class in version 3.1 of your
application it vill not be able to deserialize an object created bt version
3.0 of your application."

No, I can't go along with that. WCF serializes and desealizes objects
between the client and the service, and the client and service can be
different versions.

I seems to me that the text saying "Specilically if you add a member to a
custom class and attempt to deserialize an object that lacks that member,
the runtime will throw an exeption" will not throw any exception for me.I
tried just this first I serialized this class below without having the name
included in the ShoppingCartItem class.

Yeah, it's going to throw an exception as the XML that the object was
derived from does not have a property in the object so that it can cast
it back to the object.

I then I added this name to the class definition and then I deserialized the
file with the serialized object and I didn't get any exception. The name
field was null.
So?

So as a summary is the text in the book from Microsoft Press
wrong ?

I doubt it.

 

[Patrice]

Hello,

The text is a bit misleading they likely meant IMO "3.1 object deserialized
by version 3.0 of the app".

As a side note you may want also to check
http://msdn.microsoft.com/en-us/library/ms229752.aspx (Version Tolerant
Serialization).

Note thought that instead of analyzing the text word by word and even if you
don't have any exception, it still could cause issues in the application if
it is not prepared to deal with this. So keep just in mind that the basic
issue is that you are either loosing some information or you add new
information with default values as soon as you don't deserialize exactly
what was serialized.

 

[Tony Johansson]

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of
your
application, Specilically if you add a member to a custom class and
attempt
to deserialize an object that lacks that member, the runtime will throw
an
exeption. In other words if you add member to a class in version 3.1 of
your
application it vill not be able to deserialize an object created bt
version
3.0 of your application."

I seems to me that the text saying "Specilically if you add a member to a
custom class and attempt to deserialize an object that lacks that member,
the runtime will throw an exeption" will not throw any exception for me.I
tried just this first I serialized this class below without having the
name
included in the ShoppingCartItem class.
I then I added this name to the class definition and then I deserialized
the
file with the serialized object and I didn't get any exception. The name
field was null. So as a summary is the text in the book from Microsoft
Press
wrong ?

[Serializable]
public class ShoppingCartItem
{
public int productId = 13;
public decimal price = 10.50M;
public int qty = 20;
//string name = "test";
}

//Tony

Your test was done in the wrong order. You would need to serialize an
instance with the name field present. This represents the version 3.1
concept. Now deserialize it to a class without the name field defined,
representing the 3.0 version. You will get the exception.

No I never get any exception even if I do what you said. The bokk from
Microsoft Press might be wrong.
Note I use BinaryFormatter.

So as a summary I have done these two test.
1. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been removed and then I have deserialized
the file again back successfully.
The removed members was gone which is correct because these have been
removed from the class.
Note No exception

2. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been added and then I have deserialized
the file again back successfully.
The new added member has default values(int is 0 and reference types is
null) which is correct because these members
had not been serialized because these was added to the in the class.
Note No exception

So again can we assume that the book from Microsoft Press is wrong or is it
something that I have missed here.

//Tony

 

[Tony Johansson]

Hello,

The text is a bit misleading they likely meant IMO "3.1 object
deserialized by version 3.0 of the app".

As a side note you may want also to check
http://msdn.microsoft.com/en-us/library/ms229752.aspx (Version Tolerant
Serialization).

Note thought that instead of analyzing the text word by word and even if
you don't have any exception, it still could cause issues in the
application if it is not prepared to deal with this. So keep just in mind
that the basic issue is that you are either loosing some information or
you add new information with default values as soon as you don't
deserialize exactly what was serialized.

--
Patrice

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of
your application, Specilically if you add a member to a custom class and
attempt to deserialize an object that lacks that member, the runtime will
throw an exeption. In other words if you add member to a class in version
3.1 of your application it vill not be able to deserialize an object
created bt version 3.0 of your application."

I seems to me that the text saying "Specilically if you add a member to a
custom class and attempt to deserialize an object that lacks that member,
the runtime will throw an exeption" will not throw any exception for me.I
tried just this first I serialized this class below without having the
name included in the ShoppingCartItem class.
I then I added this name to the class definition and then I deserialized
the file with the serialized object and I didn't get any exception. The
name field was null. So as a summary is the text in the book from
Microsoft Press wrong ?

[Serializable]
public class ShoppingCartItem
{
public int productId = 13;
public decimal price = 10.50M;
public int qty = 20;
//string name = "test";
}

//Tony

No I never get any exception even if I do what you said. The bokk from
Microsoft Press might be wrong.
Note I use BinaryFormatter.

So as a summary I have done these two test.
1. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been removed and then I have deserialized
the file again back successfully.
The removed members was gone which is correct because these have been
removed from the class.
Note No exception

2. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been added and then I have deserialized
the file again back successfully.
The new added member has default values(int is 0 and reference types is
null) which is correct because these members
had not been serialized because these was added to the in the class.
Note No exception

So again can we assume that the book from Microsoft Press is wrong or is it
something that I have missed here.

//Tony

 

[Patrice]

I would have to give this a try myself to be positive. But have you tried
with properly versioned assembly ? Changing the source code of a class is
not the same as changing a version. When the deserialization code runs, the
current definition for the class is not the same definition that was used at
deserizaliation.

So for now I'm not sure your test scenario doesn't take a shortcut that
might alter the final result...

--
Patrice

Hello,

The text is a bit misleading they likely meant IMO "3.1 object
deserialized by version 3.0 of the app".

As a side note you may want also to check
http://msdn.microsoft.com/en-us/library/ms229752.aspx (Version Tolerant
Serialization).

Note thought that instead of analyzing the text word by word and even if
you don't have any exception, it still could cause issues in the
application if it is not prepared to deal with this. So keep just in mind
that the basic issue is that you are either loosing some information or
you add new information with default values as soon as you don't
deserialize exactly what was serialized.

--
Patrice

Hi!

Here is some text.
"You might have version compatibility issues if you ever attemp to
deserialize an object that has been serialized by an earlier version of
your application, Specilically if you add a member to a custom class and
attempt to deserialize an object that lacks that member, the runtime
will throw an exeption. In other words if you add member to a class in
version 3.1 of your application it vill not be able to deserialize an
object created bt version 3.0 of your application."

I seems to me that the text saying "Specilically if you add a member to
a custom class and attempt to deserialize an object that lacks that
member, the runtime will throw an exeption" will not throw any exception
for me.I tried just this first I serialized this class below without
having the name included in the ShoppingCartItem class.
I then I added this name to the class definition and then I deserialized
the file with the serialized object and I didn't get any exception. The
name field was null. So as a summary is the text in the book from
Microsoft Press wrong ?

[Serializable]
public class ShoppingCartItem
{
public int productId = 13;
public decimal price = 10.50M;
public int qty = 20;
//string name = "test";
}

//Tony

No I never get any exception even if I do what you said. The bokk from
Microsoft Press might be wrong.
Note I use BinaryFormatter.

So as a summary I have done these two test.
1. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been removed and then I have deserialized
the file again back successfully.
The removed members was gone which is correct because these have been
removed from the class.
Note No exception

2. Have an object consisting of some members in a class that have been
serialized by using a stream to a file.
Some members in the class has been added and then I have deserialized
the file again back successfully.
The new added member has default values(int is 0 and reference types is
null) which is correct because these members
had not been serialized because these was added to the in the class.
Note No exception

So again can we assume that the book from Microsoft Press is wrong or is
it
something that I have missed here.

//Tony

 

[Patrice]

So for now I'm not sure your test scenario doesn't take a shortcut that

might alter the final result...

For now I've got the same behavior here. I found the article I mentioned
before a bit ambiguous but
"In version *1.0 and 1.1* of the .NET Framework, creating serializable types
that would be reusable from one version of an application to the next was
problematic. If a type was modified by adding extra fields, the following
problems would occur:

Older versions of an application would throw exceptions when asked to
deserialize new versions of the old type.
Newer versions of an application would throw exceptions when deserializing
older versions of a type with missing data."

I'm not sure if they say that the basic behavior changed or that if .NET 2.0
now allows to alter this default behavior.

Which book is this ? Could it be a .NET 1.1 book ?

I don't have .NET 1.1 handy but it could be perhaps interesting to run the
same code under this version to see how it behaves...

Sorry for the poor help.

 

[Tony Johansson]

The book is called :
"MCTS Exam 70-536
Microsoft .NET Framework 2.0 Application Development Foundation
Self-Paced
Training Kit" and the book
is from Microsoft Press

//Tony

 

[Arne Vajhøj]

No, I don't think so. An object that has been serialized is XML and XML
is string. XML object flies around on the internet between between Web
client and Web service with the client and service using different
versions of .Net or the client can be .NET and the service is java.

Binary serialization is somewhat different from SOAP serialization.

And different .NET version is very different from different versions
of data classes.

Arne

 

[Patrice]

IMO this is something that was in the 1.1 book and that has been taken as is
into the 2.0 book when the actual feature actually changed...

Always from the same page I mentionned previously I noticed also :

"The VTS [Version Tolerant Serialization] features are enabled when using
the BinaryFormatter. Additionally, all features except extraneous data
tolerance are also enabled when using the SoapFormatter. For more
information about using these classes for serialization, see Binary
Serialization."

So it seems to me this part of the book doesn't apply any more starting with
2.0...