Deserializing a class with no parameterless constructor

Aug 29, 2011 at 2:44 PM

Currently we have an issue when loading an object from sterling when one of the properties is a complex type with no parameterless constructor.

The issue is that Sterling uses Activator.CreateInstance in the deserialization - which needs a parameterless constructor on the instance it's creating.

Is there a reason why Sterling doesn't use:

 object instance = System.Runtime.Serialization.FormatterServices.GetUninitializedObject(typeResolved);
... which doesn't require a parameterless constructor to create the instance, and is used by serializers such as the DataContractSerializer (as far as I understand)
Aug 29, 2011 at 2:55 PM

See here for more info, esp. wrt performance

Aug 29, 2011 at 3:04 PM

The primary targets for Sterling are the Silverlight and Windows Phone environments. Silverlight does not have access to the formatter services (it is internal in the Silverlight runtime) and the other optimizations aren't possible on the phone because it lacks Reflection.Emit.

That is the purpose of the custom serializers: to inform Sterling how to instantiate objects that don't have parameterless constructors.

Aug 29, 2011 at 3:08 PM

Thanks for that Jeremy - would it not be possible for Sterling to call into a private empty constructor?

This is how we currently get around WCF serialization on our silverlight clients, while at the same time not compromizing the design of the class.

Aug 29, 2011 at 3:11 PM

How exactly are you calling the private constructor - Sterling wouldn't have access to it. A protected one with the assembly tagged "internalsvisibleto" might work, unless I'm missing something.

Aug 30, 2011 at 7:39 AM

I'm not entirely sure - I just know that one of our objects that come over the wire (we tell WCF proxy to reuse objects in referenced assemblies) has a private empty constructor
which WCF calls into - at least that's what the comments in the code say....
I'll dig a bit more and post here if I find anything useful.

The internalsVisibleTo would also be something to consider - thx.