When not to use ISerializable and IDeserializationCallback

When you need to serialize something else under the hood (i.e. for backwards compatibility or for performance, see the previous blog on that topic), it is tempting to use the ISerializable interface (and in some cases, the IDeserializationCallback interface or the OnDeserialized attribute). However, these have important limitations that often make it easier to create a separate type for serialization, instead of using the interfaces.

1. On deserialization, the constructor that's implicitly a part of ISerializable is invoked at an undefined point in the deserialization of the complete graph. This means that you cannot rely on the value of any referenced objects at the point when the constructor is invoked.
   If you for instance need to examine the contents of a field of type Dictionary during deserialization, that dictionary may appear empty, even though it will contain entries when the entire graph has been deserialized.
2. IDeserializationCallback.OnDeserialization is called once the graph has been deserialized, but if multiple objects in the graph implement this interface, the ordering is not well-defined. This means that if any of your fields implement IDeserializationCallback (such as Dictionary), you cannot rely on them being completely initialized when IDeserializationCallback.OnDeserialization is called.

The workaround for point 1 is to implement IDeserializationCallback, but the workaround for point 2 is to call OnDeserialization on the field yourself (suggested in this blog post), which may or may not work, as the binary serialization framework will also call this method at some point.

(Incidentally, the workaround appears to work for Dictionary, so is an ugly, but functional workaround.)

Whether or not to use ISerializable and IDeserializationCallback is arguably a design choice, but the fairly involved mechanics makes the code harder to read for another programmer, and factoring the post-deserialization "fixup" code into a code path separate from the .NET serialization system may be a better choice when maintainability is concerned.

(See separate blog post on this.)