That depends on how you do it. I'm assuming you're serializing to XML
using an IXmlSerializable implementation. In that case, you're pretty
much in charge of the serialization and therefore the behavior under
fringe cases.
If this is the case, the story goes something like this:
1) You have your object. You create an XmlSerializer that'll spit out
either a file or a stream containing your XML upon request. You can
either tie the stream to blob access or turn the stream in to a string
and write it parametrically.
2) When you get your object back, you get the same, either a string or
a stream. You create an XmlSerializer and pass it your data as a
stream.
3) It'll call your null constructor then the implemented ReadXml()
method. Whatever you've chosen to write in the method will work as
written.
The implication of this is that you can make your ReadXml() method as
robust to change as you want. If the version 1.0 object has members A
and B and version 2.0 adds C, everything *can* work out if ReadXml() is
overridden correctly and C is nullable or defaultable.
As far as properties and such, you're on your own. Serialization
couldn't care less about anything outside the IXmlSerializable
implementation.
Stephan
Spam Catcher wrote:
Hi All,
I have a question concerning serialization in .NET.
If I serialize an object to a database and then I change the object in code
(i.e. add a property, rename a property, delete a property) will my object
deserialize correctly?
Will it throw an exception - or will it deserialize whatever it can?
If serialization is going to throw an error, is there a way to do a "best
effort" deserialization or handle changed objects?
Thanks!