By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,333 Members | 1,060 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,333 IT Pros & Developers. It's quick & easy.

.NET Serialization Quest

P: n/a
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!
Nov 14 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a

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!
I have another question: how are you serializing your objects to the
database? I just started work on a similar problem and I haven't even
gotten the objects to the database yet. If I can get that far, I'll let
you know how well they come back out of the database.

Nov 14 '06 #2

P: n/a

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!
I have another question: how are you serializing your objects to the
database? I just started work on a similar problem and I haven't even
gotten the objects to the database yet. If I can get that far, I'll let
you know how well they come back out of the database.

Nov 14 '06 #3

P: n/a
lo*********@gmail.com wrote in news:1163520931.928255.279730
@i42g2000cwa.googlegroups.com:
I have another question: how are you serializing your objects to the
database? I just started work on a similar problem and I haven't even
gotten the objects to the database yet. If I can get that far, I'll
let
you know how well they come back out of the database.
Here's my code:

Public Shared Function Serialize(ByVal instance As Object) As String
Dim _Serializer As New SoapFormatter

Using _MS As New MemoryStream
Try
_Serializer.Serialize(_MS, instance)

Return System.Text.Encoding.ASCII.GetString(_MS.ToArray)
Catch ex As Exception
Return ""
End Try
End Using

End Function

Public Shared Function Deserialize(ByVal XML As String) As Object
Dim _Serializer As New SoapFormatter

Using _MS As New MemoryStream
(System.Text.Encoding.ASCII.GetBytes(XML))
Try
Return _Serializer.Deserialize(_MS)
Catch ex As Exception
Return Nothing
End Try
End Using
End Function
Nov 14 '06 #4

P: n/a
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!
Nov 14 '06 #5

P: n/a
First, you need to separate xml-serialization and
binary/SOAP-serialization; they work differently.
When adding fields/properties:
For binary, you can look at [OptionalField], or provide your own "best
efforst" implementation via ISerializable without too much trouble.

For xml, you can look at [DefaultValue], which has the effect of making
a property optional. You could also implement IXmlSerializable, but
IIRC it is a pig (providing the schema, mainly).

When deleting: you tell me. A simple test app should take about 3
minutes to write...

Marc

Nov 14 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.