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