This project has moved and is read-only. For the latest updates, please go here.

Deserializing objects with no default constructor

Jul 3, 2008 at 8:55 AM
Hello, I am experiencing some issues when trying to deserialize a class which doesn't have a default constructor. I looked into the code and noticed that when no default constructor is found the serializer looks for a parameterized constructor and tries to match object property names with constructor argument names.

The problem is that the usual naming convention implies that argument names are camel case, while property names are pascal case, and since the match is performed with case sensitivity the serializer is not capable of doing the right match. The workaround I found was to perform a case insensitive match between constructor argument names and property names.

I can submit a patch if you like.
Jul 8, 2008 at 1:45 PM
I stumbled over the same problem today using version 1.3.1. Here, the deserialization process simply fails if no default constructor is defined. I solved the problem for me by replacing the call to Activator.CreateInstance() by calling FormatterServices.GetUnintializedObject().

Furthermore, I think, matching constructors in the deserialization process should not be implicit. I suggest to define an constructor attribute, where the matching algorithm (for example converting pascal to camel case), can be defined.
Jul 8, 2008 at 4:00 PM
Using FormatterServices.GetUninitializedObject sounds like a good idea, and would replace the implicit argument matching process. I don't know what the project owner thinks about this, but it would be worth creating a patch.
Aug 2, 2008 at 12:37 PM
I have changed it so that the serializer does a case insensitive match first. If there are multiple results returned (e.g. Param1 and param1 both matching against param1) then it will fall back to case sensitive. This should solve the pascel case vs camal case issue while remaining safe.