Serialization questions

[SStory]

My app is near completed for the basic feature of version 1.0.

I have an extensive object model and I now want to persist my objects using
serialization.
I have chosen binaryformatter to serialize, and custom serialization, which
I understand will allow me the flexibility of not breaking old things when I
add members to classes in the future and send to existing customers.

1.) is there anything else to consider with the custom serialization

2.) when doing the info.addvalue in GetObjectData, if one of the members of
my class is an instance of another class, do I go ahead and add it--and that
somehow calls the serialization process of that class to fullfill this?

3.) some of my classes are collections. They inherited from collectionbase.
Is collection base not serializable? Assuming it may not be serializable,
the documentation says serialization will fail. If so, how in the world can
I handle this issue? I need to serialize all items of the collection base
and then deserialize them.

Are there any other comments about this? Any other gotchas?

Thanks a bunch.

Shane

[Cor Ligthert]

SSStory,

The nicest I have seen, I cannot make it nicer.

\\\Tom Shelton
Private Function SerializeFontObject(ByVal fnt As Font) As String
Dim bf As New BinaryFormatter
Dim mem As New MemoryStream
Try
bf.Serialize(mem, fnt)
Return Convert.ToBase64String(mem.ToArray())
Catch
Return String.Empty
Finally
mem.Close()
End Try
End Function
Private Function DeserializeFontObject(ByVal fnt As String) As Font
Dim bf As New BinaryFormatter
Dim mem As New MemoryStream(Convert.FromBase64String(fnt))
Try
Return DirectCast(bf.Deserialize(mem), Font)
Finally
If Not mem Is Nothing Then
mem.Close()
End If
End Try
End Function
////

I hope this helps a little bit?

Cor

[SStory]

Thanks for trying.
I don't see how this answers either of my questions.
I do already know how to do the binary formatter and I have that code in
place. Just having trouble as mentioned in the original question, knowing
for one how do I serialize a class that inherits from collectionbase which
apparently isn't serializable.

And the other question also.

A third could be how do I find out if a class is serializable if I don't
have the source--like CollectionBase?

Thanks Cor,

Shane
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

SSStory,

The nicest I have seen, I cannot make it nicer.

\\\Tom Shelton
Private Function SerializeFontObject(ByVal fnt As Font) As String
Dim bf As New BinaryFormatter
Dim mem As New MemoryStream
Try
bf.Serialize(mem, fnt)
Return Convert.ToBase64String(mem.ToArray())
Catch
Return String.Empty
Finally
mem.Close()
End Try
End Function
Private Function DeserializeFontObject(ByVal fnt As String) As Font
Dim bf As New BinaryFormatter
Dim mem As New MemoryStream(Convert.FromBase64String(fnt))
Try
Return DirectCast(bf.Deserialize(mem), Font)
Finally
If Not mem Is Nothing Then
mem.Close()
End If
End Try
End Function
////

I hope this helps a little bit?

Cor

[Samuel R. Neff]

Attributes are listed in the docs. CollectionBase docs say:

<Serializable>
MustInherit Public Class CollectionBase
Implements IList, ICollection, IEnumerable

So, yes, CollectionBase is serializable.

Best regards,

Sam
On Sat, 2 Apr 2005 15:43:58 -0600, "SStory"
<Th*******@TAKEOUTTHISSPAMBUSTERsofthome.net> wrote:

Thanks for trying.
I don't see how this answers either of my questions.
I do already know how to do the binary formatter and I have that code in
place. Just having trouble as mentioned in the original question, knowing
for one how do I serialize a class that inherits from collectionbase which
apparently isn't serializable.

And the other question also.

A third could be how do I find out if a class is serializable if I don't
have the source--like CollectionBase?

Thanks Cor,

Shane

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Shane Story]

cool. I did finally find that in MSDN--DUH. Just was looking for it in the
object browser for some reason.

The other question was....

if a member of my class is a class, does deserializer also call the
mechanism for that member class automatically and handle it for you?
(assuming it is a <serializable> class of course)

Thanks,

Shane

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:k4********************************@4ax.com...

Attributes are listed in the docs. CollectionBase docs say:

<Serializable>
MustInherit Public Class CollectionBase
Implements IList, ICollection, IEnumerable

So, yes, CollectionBase is serializable.

Best regards,

Sam
On Sat, 2 Apr 2005 15:43:58 -0600, "SStory"
<Th*******@TAKEOUTTHISSPAMBUSTERsofthome.net> wrote:

Thanks for trying.
I don't see how this answers either of my questions.
I do already know how to do the binary formatter and I have that code in
place. Just having trouble as mentioned in the original question, knowing
for one how do I serialize a class that inherits from collectionbase which
apparently isn't serializable.

And the other question also.

A third could be how do I find out if a class is serializable if I don't
have the source--like CollectionBase?

Thanks Cor,

Shane

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Samuel R. Neff]

Yes, it serializes the entire object graph (hierarchy).

Sam
On Tue, 5 Apr 2005 11:04:56 -0500, "Shane Story"
<sh**************@dv-corp.com> wrote:

cool. I did finally find that in MSDN--DUH. Just was looking for it in the
object browser for some reason.

The other question was....

if a member of my class is a class, does deserializer also call the
mechanism for that member class automatically and handle it for you?
(assuming it is a <serializable> class of course)

Thanks,

Shane

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:k4********************************@4ax.com.. .

Attributes are listed in the docs. CollectionBase docs say:

<Serializable>
MustInherit Public Class CollectionBase
Implements IList, ICollection, IEnumerable

So, yes, CollectionBase is serializable.

Best regards,

Sam

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Shane Story]

Thanks Samuel.

Considering what else I have read on the subject, it seems that if you
serialize and object and later make any changes, that the things serialized
before the change would not be readable. For this reason custom
serialization seems better. Would you agree?

Thanks
"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:su********************************@4ax.com...

Yes, it serializes the entire object graph (hierarchy).

Sam
On Tue, 5 Apr 2005 11:04:56 -0500, "Shane Story"
<sh**************@dv-corp.com> wrote:

cool. I did finally find that in MSDN--DUH. Just was looking for it in
the
object browser for some reason.

The other question was....

if a member of my class is a class, does deserializer also call the
mechanism for that member class automatically and handle it for you?
(assuming it is a <serializable> class of course)

Thanks,

Shane

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:k4********************************@4ax.com. ..

Attributes are listed in the docs. CollectionBase docs say:

<Serializable>
MustInherit Public Class CollectionBase
Implements IList, ICollection, IEnumerable

So, yes, CollectionBase is serializable.

Best regards,

Sam

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Samuel R. Neff]

Unfortunately there's a huge leap between XmlSerializer and custom
serialization--quick and dirty vs totally do it yourself. There are
lots issues that XmlSerializer doesn't address and for that reason a
lot of people (most it seems) recommend doing it yourself.

XmlSerializer does do a good job for what it's programmed to do, so if
you can use it in your situation I'd suggest doing so--you can always
switch to custom if you really need more functionality. We of course
have the same concerns over versioning that you do and have an
architecture to get around it (well, planned architecture) by using a
bookmarked XML reader combined with XSLT.

Basically, we'll read the XML up to a Version attribute on the root
element. If that matches the current, then reset the reader to the
beginning and process as normal.

If the version is old, then reset the reader and perform a
transformation on it to get the new format (requires writing XSLT,
which some consider more complicated then writing a custom
serializer).

If the version is newer, then cancel or take whatever action is
appropriate in your application.

Here's a bookmarked XML reader from MS:

http://msdn.microsoft.com/XML/Buildi...mlBkMkRead.asp

It has some issues of it's own--it won't even compile as distributed.
But once they're fixed, it seems to work pretty well (fixes: invalid
boolean check at end with bool != null, and a Debug.Assert that always
gets triggered).

HTH,

Sam
On Tue, 5 Apr 2005 14:41:12 -0500, "Shane Story"
<sh**************@dv-corp.com> wrote:

Thanks Samuel.

Considering what else I have read on the subject, it seems that if you
serialize and object and later make any changes, that the things serialized
before the change would not be readable. For this reason custom
serialization seems better. Would you agree?

Thanks

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[SStory]

Thanks Samuel for all of your help.

I am trying to use binaryformatter. I have no trouble saving (serializing),
but when I go to deserialize I always get errors. It appears that I cannot
set a breakpoint or anything to discover where the problem is.

I am serializing by implementing ISerializable: The GetObjectData method &
the custom Constructor.

The last problem I got was an exception--TargetInvocationException class to
be exact.

My object model has things like the following to deal with:

MDIForm (which has a bunch of frmA's)
frmA
which has a Workspace object. This object has some members and then some
other objects.

for the sake of this newsgroup let me give an example scenario and see what
I should do.

Workspace has a reference to the form that "owns" it (this is not
serializable of course).

So imagine
class workspace
private A as single
private B as single
private ParentForm as frmA
private objSomething as Something
end class

class Something
'class something has a reference to the parentworkspace to which it
belongs
private ParentWorkSpace as workspace
end class

my thought was, in GetDataObject for workspace object to just do the
following:
info.addvalue("A",A)
info.addvalue("B",B)
info.addvalue("objSomething",Something)

and then in the specialized contstructor for deserializing
A=info.getsingle("A")
B=info.getsingle("B")

objSomething=ctype(info.getvalue("objSomething",ge ttype(something)),somethin
g)
'then at this point, maybe call a method on objSomething to set the
parent workspace object
'reference to this object
objSomething.SetParentWorkspace=me

I would do the same thing to the Workspace object itself after being
deserialized, it would set the ParentForm with a method.

Am I on the wrong track? Any ideas, from you or any other group member
about the exception.

Also any ideas on how to debug this stuff, since it seems to just happen and
not allow me to step into the call, which I assume just eventually calls the
constructor.

Thanks for all your help.

Shane

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:ot********************************@4ax.com...

Unfortunately there's a huge leap between XmlSerializer and custom
serialization--quick and dirty vs totally do it yourself. There are
lots issues that XmlSerializer doesn't address and for that reason a
lot of people (most it seems) recommend doing it yourself.

XmlSerializer does do a good job for what it's programmed to do, so if
you can use it in your situation I'd suggest doing so--you can always
switch to custom if you really need more functionality. We of course
have the same concerns over versioning that you do and have an
architecture to get around it (well, planned architecture) by using a
bookmarked XML reader combined with XSLT.

Basically, we'll read the XML up to a Version attribute on the root
element. If that matches the current, then reset the reader to the
beginning and process as normal.

If the version is old, then reset the reader and perform a
transformation on it to get the new format (requires writing XSLT,
which some consider more complicated then writing a custom
serializer).

If the version is newer, then cancel or take whatever action is
appropriate in your application.

Here's a bookmarked XML reader from MS:

http://msdn.microsoft.com/XML/Buildi...mlBkMkRead.asp
It has some issues of it's own--it won't even compile as distributed.
But once they're fixed, it seems to work pretty well (fixes: invalid
boolean check at end with bool != null, and a Debug.Assert that always
gets triggered).

HTH,

Sam
On Tue, 5 Apr 2005 14:41:12 -0500, "Shane Story"
<sh**************@dv-corp.com> wrote:

Thanks Samuel.

Considering what else I have read on the subject, it seems that if you
serialize and object and later make any changes, that the things serializedbefore the change would not be readable. For this reason custom
serialization seems better. Would you agree?

Thanks

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

[Chris Murphy via DotNetMonster.com]

Both classes need to have the "<serializeable()>" attribute before you can
properly serialize/deserialize. FYI, and you may already know this, if the
number of members in either of the classes changes, it'll render your
serialized object useless -- meaning that deserialization of your object
will throw exceptions.

If I were you I would look at XML serialization if you want to persist the
state of your application. I know that there are a lot of developers out
there who will probably flame me for say so, but you can essentially use
*.config files to save the information. Config files are troublesome in
that some systems you might deploy on have strict security settings for
user accounts, and most will only have ONE location in which to write to.
There are ways to find out where these locations are (based on the user
account...) check out references to "IsolatedStorage" (C:\Documents and
Settings\<user>\Local Settings\Application Data\IsolatedStorage). If you go
with the *.config file route, take some time to explore google for the pros
and cons. I'm personally using it in an application I'm developing, and it
seems to be working well with different security settings/user accounts.

--
Message posted via http://www.dotnetmonster.com

[Shane Story]

Thanks for the opinion.

Seems ridiculous that something so vital, is so difficult.

I was thinking if I did custom serialization that my object wouldn't be
trashed even if I added a new param because I could check for that.

The problems I get are such as:

1.) in GetObjectData, for a class that inherits CollectionBase I write out
normal members, then I think I am supposed to do
mybase.GetObjectData(info,context) to let collectionbase do its
serialization, but that seems to be private and unaccessable, so I can't
seem to do this.

Is this true? Do I need to call this for each member of my class that is
actually another class?

2.) When something goes wrong I don't really know how to debug it.

Anyone have any comments on these comments.

Thanks again,

Shane

"Chris Murphy via DotNetMonster.com" <fo***@DotNetMonster.com> wrote in
message news:01******************************@DotNetMonste r.com...

Both classes need to have the "<serializeable()>" attribute before you can
properly serialize/deserialize. FYI, and you may already know this, if the
number of members in either of the classes changes, it'll render your
serialized object useless -- meaning that deserialization of your object
will throw exceptions.

If I were you I would look at XML serialization if you want to persist the
state of your application. I know that there are a lot of developers out
there who will probably flame me for say so, but you can essentially use
*.config files to save the information. Config files are troublesome in
that some systems you might deploy on have strict security settings for
user accounts, and most will only have ONE location in which to write to.
There are ways to find out where these locations are (based on the user
account...) check out references to "IsolatedStorage" (C:\Documents and
Settings\<user>\Local Settings\Application Data\IsolatedStorage). If you
go
with the *.config file route, take some time to explore google for the
pros
and cons. I'm personally using it in an application I'm developing, and it
seems to be working well with different security settings/user accounts.

--
Message posted via http://www.dotnetmonster.com