Serialized Type data not used to resolve Converters during deserialization


When deserializing, a converter is resolved using the passed in type data. The type data passed in depends on what current deserialization operation is occurring.
If it's the root object, the type data is the type passed in to the Deserialize method by the caller (This can be null).
If the parent member returns a Dictionary<,> or List<> type, the type data is based on the generic parameters of the Dictionary or List.
If the parent member returns a single instance, the type data is based on the reflected return type of the property.
When a converter is not resolved, everything works as expected as the instance data is first deserialized, and then constructed using the deserialized type data (if available).
However when a converter is resolved, it is passed in the type information is was resolved from. This may be a base class compared to the type data serialized into the actual instance data.
This causes 2 problems.
Firstly, if a type is not passed in to the initial Deserialize call, a converter will never be resolved, even if there is a valid one for the instance serialized, and that instance has type data serialized with it.
Secondly, a CustomCreationConverter may be resolved for the collectable type of a list or dictionary, or the return type of a property. This then attempts to create an instance of that type, and pass it back to the deserializer to be populated. However the serialized instance data may contain type information for a more derived type, which will never be passed to the Create method, and hence never created.
The attached svn patch file includes unit tests for the problem, and my attempt at fixing the problem. It works (1 unit test is broken but that is more a matter of semantics than broken functionality), but I ended up having to 'munge' the code a little bit (Needed to change all the JsonReader parameters to 'ref' params for deserialization).

file attachments

Closed Jun 11, 2010 at 12:46 PM by JamesNK


JamesNK wrote Jun 11, 2010 at 12:46 PM

I'm glad you resolved your issue but I don't want to make such broad sweeping changes to fix one very specific use.

wrote Jun 11, 2010 at 12:46 PM

wrote Feb 22, 2013 at 1:48 AM

wrote May 16, 2013 at 12:37 PM