Serializing

I thought I understood fully serialization, but for some reason when building something for WWF I forgot a very important thing and a day was lost trying to find the cause of a mysterious problem.

The problem came because the workflow I persisted wouldn’t resume as I described here.

At the end, I found the problem and the exception was that for a type contained in my worflow the contructor could not be found. But I had spesifically declared a public contructor and marked is as Serializable.

I decided to debug in the native code which is not easy, and at some point I found where the exception about the constructor was througn.

RuntimeSerializer was requesting through reflection a constructor that took 2 type arguments. I wen’t back to my class declaration, which was a child of Dictionary<,>. I decided to look for a base contructor that took 2 arguments. I was going nuts, when I saw the constructor with these parameters
(SerializationInfo info, StreamingContext context)

It all came clean to me then. Dictionary<,> implements ISerializable. This means that custom serialization is done when required. When serializing its ok, because ISerializable.GetObjectData is called. But when deserializing a specific constructor with the above signature was required that I had hidden because I didn’t specifically declare it in my class.

The whole mistake was really silly, I just wanted to emphasize on the caution that need to be taken when subclassing objects with ISerializable.

I would like to make a comment. Runtime serializer should through a more specific exception about the problem. It searched for a very specific constructor that can be easily forgoten when sublassing a class that implement ISerializable


3 comments

  1. Pingback: Persisted Worklow won’t resume « Alex Sarafian as Developer

    • ISerializable is mainly for .NET Binary Serialization.
      XmlSerialization just does reflection, if no special attributes are defined.


Leave a reply to Sarafian Alex Cancel reply