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
Pingback: Persisted Worklow won’t resume « Alex Sarafian as Developer
Perhaps this could help:
http://www.hanselman.com/blog/CategoryView.aspx?category=XmlSerializer
ISerializable is mainly for .NET Binary Serialization.
XmlSerialization just does reflection, if no special attributes are defined.