Serialize, or Not to Serialize--That is the Question

What do you think are the issues you can face whith the Serializing and Deserializing of your class
And how complex is your class, I mean keeping in mind the problems you are going to face can you not design sort of your own schema for persisting the object in XML. You manually persist the state of this object in this specially designed xml schema so that the issues in generic serialization is solved.
It might be easier said than done, but would really depend on the two questions, what are the potential issues and how easy or difficult it is to persist the class manually so that it can be easily reconstructed

With 1.1, if you serialized a class, and then changed the class, derializing it would give you an exception.  Is 2.0 any better at that, and if so how?

If you are suggesting designing my own schema, what would be the "best" way?  Could a design pattern be applied here?  

Let's say that the class is simple know, but it won't always be that way.  Over time, it could grow to be a complex monster, so take the problem from the perspective of the "most" complex.

Bob

A.,

1) Does this apply to 2.0, or was this 1.1 thinking?  

2) Is this the "best" way?  

3) When you say, "depending on what you serialize", it's difficult to say since the future is not as clear as the present or the past.  So, I would like to find an agile way of handling it, and I was hoping to find an elegant solution, versus a kludge.

Thanks,
Bob

Well, I don't have a Hashtable, but I do have an OrderedDictionary, which I believe is fully serializable.  I have seen problems with serializing Hashtable, even though it is marked as serializable.  

I was thinking, though, about all the different scenarios, and trying to decide the best course of action for me.  One thing is that XML files can add overhead, so if I extend the application to serialize XML, then it could be terribly inefficient.  So, you think about binary formatters, and sending byte arrays.  But, those are difficult to debug, since XML text is easier to use.  What you end up doing is coming up with routines to take the byte arrays and generating text.

I believe that object persistence/serialization is a deeper subject than one question can touch on, but I need to start somewhere.

Thanks for the open discussion,
Bob

Has anyone read this CodeProject entry about Fast Serializer?  

  Fast Serializer
  http://www.thecodeproject.com/useritems/Fast_Serializer.asp

My friend mentioned it yesterday, but I haven't seen it before, and I don't have enough knowledge to have an informed opinion on it either way?

Bob

It was something about the fact the the serializer uses Reflection, and by skipping that step with generated code, you can realize a 700x gain in serialization speed.  It was only meant, I believe for very stable classes, and not useful in my particular environment, at this time, but I still wanted to see how it could fit the future.

Bob

I think that with 2.0, serialization is not so bad when a class is dynamic.  I like the idea of the OptionalField attribute.  I will have to try that out.

Thanks,
Bob

A. A problem with the implementation of ISerializable is that VB doesnt like reimplementation, therefore if an abstract class and a class that inherits it, want to implement the ISerializable, VB raises warnings.

B. The SOAP serializer doesnt serialize generics, and not seems to do so in future (according to a MS thread i've read)