Quote:Original post by DvDmanDT
The reason for this is that BinaryFormatter sometimes have problems with objects that change from serialization to deserialization. This happens quite often in my development process. Implenting ISerializable didn't help.
It is to be expected that binary serialization breaks if you modify the object being serialized/deserialized. Binary serialization can be thought of as taking the object and flattening it into a bytestream. There's no cataloguing or marking of individual pieces of data as with the XML serializer. If the object that we're attempting to load the serialized data into doesn't match exactly the runtime cannot deal with it -- type safety is extremely important in .NET. (Reminds me of the old EnvyMUD days when I'd use the first byte of a memory structure to determine what type of object it was... neat trick, but ultimately not safe.)
This lack of individual data separation is one of the reasons why the binary serializer beats the pants off the XML serializer in terms of data saved/memory used for serialization. The XML serializer uses "<RandomInt>4</RandomInt>" while the binary serializer uses "0004".
The XML formatter works in the opposite manner, which is why it only serializes public fields/properties. If a property doesn't exist, the XML formatter continues without complaining.
With ISerializable it IS noted that there is no guarantee as to the order of recreation. (I think this has more to do with the SerializationInfo object being parsed completely by the constructor before moving on to the next object in the graph than anything else.)
Can you not handle what you need to using the OnSerializing, OnSerialized, OnDeserializing, and OnDeserialized attributes? When one of the objects/properties/fields you're having problems with is either being prepared to be deserialized or has been, take whatever steps are necessary? Or is that your reference to breaking into parts/complexity?
With that said, custom serialization isn't bad. Especially if you're more concerned with storing data in a file rather than sending the object across remoting boundaries or app domains. I'm not a big fan of declarative programming (attribute based decision making) as it tends to hide itself and how it works.