[Serializable] Changes

[db_from_mn]

I'm creating a new app that will have a number of project settings. Rather
than save all these to the registry, I'd like to create a serializable class
to define all of the settings, and save them to a project file.
I'm concerned that if I ever change the class, then the prior saved files
will be rendered useless. Is this true?
What if I just added fields, properties and methods to the class?

Thanks in advance for the help,
Dennis

[Brendan Grant]

To answer this question... let me quickly go over how serialization and
deserialization works.

When you are dumping your serializable class to a file, the system uses
reflection to know the names and types of the different properties that are
to be written.

When reading from the file, the system will create an instance of the class
with the default constructor and iterate through the file, reading each
property and attempts to find a matching property in the class it created, if
it finds it, it sets the value, if not it moves onto the next one.

Because of this, the serialized output is not directly require a given
structure within the class it will be applied to, so if you add a new
property to your class and read in an old file, when complete that property
will simply have the default value as specified by the class and it’s
constructor. The upside of this too, is that if you remove a property and
load a doc that has this property, the differences will be ignored.

Brendan

"db_from_mn" wrote:

I'm creating a new app that will have a number of project settings. Rather
than save all these to the registry, I'd like to create a serializable class
to define all of the settings, and save them to a project file.
I'm concerned that if I ever change the class, then the prior saved files
will be rendered useless. Is this true?
What if I just added fields, properties and methods to the class?

Thanks in advance for the help,
Dennis

[db_from_mn]

Hello Brendan,
Thanks a lot. This is great news!
This is the second time in recent days that I've run across "reflection". I
need to study up on that.
Thanks again,
Dennis

"Brendan Grant" wrote:

To answer this question... let me quickly go over how serialization and
deserialization works.

When you are dumping your serializable class to a file, the system uses
reflection to know the names and types of the different properties that are
to be written.

When reading from the file, the system will create an instance of the class
with the default constructor and iterate through the file, reading each
property and attempts to find a matching property in the class it created, if
it finds it, it sets the value, if not it moves onto the next one.

Because of this, the serialized output is not directly require a given
structure within the class it will be applied to, so if you add a new
property to your class and read in an old file, when complete that property
will simply have the default value as specified by the class and it’s
constructor. The upside of this too, is that if you remove a property and
load a doc that has this property, the differences will be ignored.

Brendan

"db_from_mn" wrote:

I'm creating a new app that will have a number of project settings. Rather
than save all these to the registry, I'd like to create a serializable class
to define all of the settings, and save them to a project file.
I'm concerned that if I ever change the class, then the prior saved files
will be rendered useless. Is this true?
What if I just added fields, properties and methods to the class?

Thanks in advance for the help,
Dennis

[Frans Bouma [C# MVP]]

Brendan Grant wrote:

To answer this question... let me quickly go over how serialization
and deserialization works.

When you are dumping your serializable class to a file, the system
uses reflection to know the names and types of the different
properties that are to be written.

When reading from the file, the system will create an instance of the
class with the default constructor and iterate through the file,
reading each property and attempts to find a matching property in the
class it created, if it finds it, it sets the value, if not it moves
onto the next one.
no, each private member variable, not each property.
Also, if a private member variable is found in the serialized data (in
the info block) and not in the object it has to fill, you'll get an
exception.

This is for example shown when you serialize a sortedlist with strings
using the binary formatter in .NET 1.1 SP1 and deserialize it in .NET
1.1. .NET 1.1 SP1 added a private member variable to the string
comparer, which causes when deserializing the data on .NET 1.1 without
SP1. (I believe it's with the string comparer class, could be another
comparer class, I don't have an example ready)

The other way around of course works: if a member variable isn't
present in the data, it won't be filled.
Because of this, the serialized output is not directly require a
given structure within the class it will be applied to, so if you add
a new property to your class and read in an old file, when complete
that property will simply have the default value as specified by the
class and it’s constructor. The upside of this too, is that if you
remove a property and load a doc that has this property, the
differences will be ignored.

No, that last remark is definitely not true.

To circumvent deserialization issues, I wrote a utility class which
has methods like InfoGetString, InfoGetValue etc. which accept the info
block, name and type (if applicable) and contain a try/catch block and
return a default value if the field isn't there, for example when the
class structure changed in a new version.

This of course requires ISerializable to be implemented, but it also
makes sure every old version of the data can be read back and converted
to a new internal version without exceptions.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[db_from_mn]

Hello Frans,
Thanks for the clarifications.
Dennis

"Frans Bouma [C# MVP]" wrote:

Brendan Grant wrote:

To answer this question... let me quickly go over how serialization
and deserialization works.

When you are dumping your serializable class to a file, the system
uses reflection to know the names and types of the different
properties that are to be written.

When reading from the file, the system will create an instance of the
class with the default constructor and iterate through the file,
reading each property and attempts to find a matching property in the
class it created, if it finds it, it sets the value, if not it moves
onto the next one.

no, each private member variable, not each property.
Also, if a private member variable is found in the serialized data (in
the info block) and not in the object it has to fill, you'll get an
exception.

This is for example shown when you serialize a sortedlist with strings
using the binary formatter in .NET 1.1 SP1 and deserialize it in .NET
1.1. .NET 1.1 SP1 added a private member variable to the string
comparer, which causes when deserializing the data on .NET 1.1 without
SP1. (I believe it's with the string comparer class, could be another
comparer class, I don't have an example ready)

The other way around of course works: if a member variable isn't
present in the data, it won't be filled.

Because of this, the serialized output is not directly require a
given structure within the class it will be applied to, so if you add
a new property to your class and read in an old file, when complete
that property will simply have the default value as specified by the
class and it’s constructor. The upside of this too, is that if you
remove a property and load a doc that has this property, the
differences will be ignored.

No, that last remark is definitely not true.

To circumvent deserialization issues, I wrote a utility class which
has methods like InfoGetString, InfoGetValue etc. which accept the info
block, name and type (if applicable) and contain a try/catch block and
return a default value if the field isn't there, for example when the
class structure changed in a new version.

This of course requires ISerializable to be implemented, but it also
makes sure every old version of the data can be read back and converted
to a new internal version without exceptions.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Mark Rance]

Frans Bouma [C# MVP] wrote:

Brendan Grant wrote:

To answer this question... let me quickly go over how serialization
and deserialization works.

When you are dumping your serializable class to a file, the system
uses reflection to know the names and types of the different
properties that are to be written.

When reading from the file, the system will create an instance of the
class with the default constructor and iterate through the file,
reading each property and attempts to find a matching property in the
class it created, if it finds it, it sets the value, if not it moves
onto the next one.

no, each private member variable, not each property.
Also, if a private member variable is found in the serialized data (in
the info block) and not in the object it has to fill, you'll get an
exception.

This is for example shown when you serialize a sortedlist with strings
using the binary formatter in .NET 1.1 SP1 and deserialize it in .NET
1.1. .NET 1.1 SP1 added a private member variable to the string
comparer, which causes when deserializing the data on .NET 1.1 without
SP1. (I believe it's with the string comparer class, could be another
comparer class, I don't have an example ready)

The other way around of course works: if a member variable isn't
present in the data, it won't be filled.

Because of this, the serialized output is not directly require a
given structure within the class it will be applied to, so if you add
a new property to your class and read in an old file, when complete
that property will simply have the default value as specified by the
class and it’s constructor. The upside of this too, is that if you
remove a property and load a doc that has this property, the
differences will be ignored.

No, that last remark is definitely not true.

To circumvent deserialization issues, I wrote a utility class which
has methods like InfoGetString, InfoGetValue etc. which accept the info
block, name and type (if applicable) and contain a try/catch block and
return a default value if the field isn't there, for example when the
class structure changed in a new version.

This of course requires ISerializable to be implemented, but it also
makes sure every old version of the data can be read back and converted
to a new internal version without exceptions.

FB

Along those lines, I have wondered how you can deserialize into an
object...which very often includes a collection of nodes...how do you
them delete one or more items from the collection and then serialize it
again???

-Mark

[Mark Rance]

Mark Rance wrote:

Frans Bouma [C# MVP] wrote:

Brendan Grant wrote:

To answer this question... let me quickly go over how serialization
and deserialization works.

When you are dumping your serializable class to a file, the system
uses reflection to know the names and types of the different
properties that are to be written.

When reading from the file, the system will create an instance of the
class with the default constructor and iterate through the file,
reading each property and attempts to find a matching property in the
class it created, if it finds it, it sets the value, if not it moves
onto the next one.

no, each private member variable, not each property. Also, if
a private member variable is found in the serialized data (in
the info block) and not in the object it has to fill, you'll get an
exception.

This is for example shown when you serialize a sortedlist with
strings
using the binary formatter in .NET 1.1 SP1 and deserialize it in .NET
1.1. .NET 1.1 SP1 added a private member variable to the string
comparer, which causes when deserializing the data on .NET 1.1 without
SP1. (I believe it's with the string comparer class, could be another
comparer class, I don't have an example ready)

The other way around of course works: if a member variable isn't
present in the data, it won't be filled.

Because of this, the serialized output is not directly require a
given structure within the class it will be applied to, so if you add
a new property to your class and read in an old file, when complete
that property will simply have the default value as specified by the
class and it’s constructor. The upside of this too, is that if you
remove a property and load a doc that has this property, the
differences will be ignored.

No, that last remark is definitely not true.
To circumvent deserialization issues, I wrote a utility class which
has methods like InfoGetString, InfoGetValue etc. which accept the info
block, name and type (if applicable) and contain a try/catch block and
return a default value if the field isn't there, for example when the
class structure changed in a new version.

This of course requires ISerializable to be implemented, but it also
makes sure every old version of the data can be read back and converted
to a new internal version without exceptions.

FB

Along those lines, I have wondered how you can deserialize into an
object...which very often includes a collection of nodes...how do you
them delete one or more items from the collection and then serialize it
again???

-Mark

How come every time I post this question there are no responses at
all??? Is this just a very stupid question or does no one know how to
do this?
Is my question, as written unclear to people or is it something else
altogether...?

-Mark