How to deserialize class without calling a constructor?

Question

I'm using Json.NET in my WCF data service.

Here's my class (simplified):

[DataContract]
public class Component
{
    public Component()
    {
        // I'm doing some magic here.
    }
}

How can I deserialize that class without invoking a constructor using JsonConvert.DeserializeObject?

Sorry if not clear, feel free to ask questions.

Not possible AFAIK. A constructor is always executed when creating an instance. — Maarten, Dec 19 '12 at 08:12
@Maarten http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices.getsafeuninitializedobject.aspx — Igor Shastin, Dec 19 '12 at 08:13
You can add an `Initialize` method with your logic. That requires a consuming code change unfortunately. — Steve B, Dec 19 '12 at 08:18
@SteveB: Initialization methods fails if someone forgets to call them (or don't understand that they have to be called) — jgauffin, Dec 19 '12 at 08:21
@jgauffin: you are right. Your solution is better, but what about if there is no parameter to pass to the constructor? — Steve B, Dec 19 '12 at 08:22

jgauffin · Answer 1 · 2012-12-19T08:20:17.177

A constructor is always invoked. I usually have two constructors. One for serialization (the default constructor) and one for all "regular" code:

[DataContract]
public class Component
{
    // for JSON.NET
    protected Component()
    {
    }

    public Component(allMandatoryFieldsHere)
    {
        // I'm doing some magic here.
    }
}

In that way I can also make sure that the dev specify all information which are required.

However, I do not really recommend that you use anything but DTO's when transfering information since it's otherwise possible to circumvent the encapsulation of your objects (anyone could initialize any field with any value). Well. If you use anything but anemic models.

Using FormatterServices.GetSafeUninitializedObject is imho therefore an ugly workaround, since no one can tell that you create all objects in an unintialized way. Constructor initialization is there for a reason. It's better that the classes can tell that it's OK to not call the real constructor by providing a "serialization" constructor as I suggested.

But as far as I know, default `DataContractJsonSerializer` doesn't invoke a constructor. — Igor Shastin, Dec 19 '12 at 08:22
@IgorShastin: That's why you only should use it with DTO's. JSON.NET is more well behaving. — jgauffin, Dec 19 '12 at 08:23

score 8 · Accepted Answer · answered Dec 19 '12 at 09:51

8

You could create a class that inherits from CustomCreationConverter and use FormatterServices.GetSafeUninitializedObject to create your object. It skips calling the constructor.

More about CustomCreationConverter here.
Placing [JsonObject(MemberSerialization.Fields)] on a class will make Json.NET use FormatterServices.GetSafeUninitializedObject by default (although Fields mode will also serialize public/private fields rather than public properties which you may not want).
Move the logic you don't want run outside of the default constructor.

answered Dec 19 '12 at 09:51

James Newton-King

48,174
24
109
130

Thank you very much! For some reason, when I tried `[JsonObject(MemberSerialization.Fields)]`, it produced `StackOverflowException`. So I prefer first variant. Can you please tell me - is there a way to create universal `CustomCreationConverter` for many classes? – Igor Shastin Dec 19 '12 at 09:58
1

Copy the CustomCreationConverter source code and modify it to do what you want. It just inherits from JsonConverter - https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/Converters/CustomCreationConverter.cs – James Newton-King Dec 19 '12 at 19:34

score 3 · Answer 3 · answered Aug 25 '16 at 19:34

Others already mentioned the second constructor, but using 2 attributes: [JsonConstructor] and [Obsolete] you can do much better than leaving it up to humans to remember which one to call.

    public ChatMessage()
    {   
        MessageID = ApplicationState.GetNextChatMessageID(); // An expensive call that uses up an otherwise free ID from a limited set and does disk access in the process.
    }


    [JsonConstructor] // This forces JsonSerializer to call it instead of the default.
    [Obsolete("Call the default constructor. This is only for JSONserializer", true)] // To make sure that calling this from your code directly will generate a compiler error. JSONserializer can still call it because it does it via reflection.
    public ChatMessage(bool DO_NOT_CALL_THIS)
    {
    }

[JsonConstructor] forces JsonSerializer to call it instead of the default.
[Obsolete("...", true)] Makes sure that calling this from your code directly will generate a compiler error. JSONserializer can still call it because it does it via reflection.

Alexander · Answer 4 · 2022-12-01T08:24:53.000

The best option to avoid constructor calls on deserialization is to create special contract resolver that overrides creator function for all classes without constructor marked with JsonConstructor attribute. This way you still can force JSON.NET to call constructor if you really need it, but all other classes will be created much like in standard DataContract serializers in .NET. Here is the code:

/// <summary>
/// Special contract resolver to create objects bypassing constructor call.
/// </summary>
public class NoConstructorCreationContractResolver : DefaultContractResolver
{
    /// <summary>
    /// Creates a <see cref="T:Newtonsoft.Json.Serialization.JsonObjectContract"/> for the given type.
    /// </summary>
    /// <param name="objectType">Type of the object.</param>
    /// <returns>
    /// A <see cref="T:Newtonsoft.Json.Serialization.JsonObjectContract"/> for the given type.
    /// </returns>
    protected override JsonObjectContract CreateObjectContract(Type objectType)
    {
        // prepare contract using default resolver
        var objectContract = base.CreateObjectContract(objectType);

        // if type has constructor marked with JsonConstructor attribute or can't be instantiated, return default contract
        if (objectContract.OverrideCreator != null || objectContract.CreatedType.IsInterface || objectContract.CreatedType.IsAbstract)
            return objectContract;

        // prepare function to check that specified constructor parameter corresponds to non writable property on a type
        Func<JsonProperty, bool> isParameterForNonWritableProperty =
            parameter =>
            {
                var propertyForParameter =
                    objectContract.Properties.FirstOrDefault(property => property.PropertyName == parameter.PropertyName);

                if (propertyForParameter == null)
                    return false;

                return !propertyForParameter.Writable;
            };

        // if type has parameterized constructor and any of constructor parameters corresponds to non writable property, return default contract
        // this is needed to handle special cases for types that can be initialized only via constructor, i.e. Tuple<>
        if (objectContract.CreatorParameters.Any(parameter => isParameterForNonWritableProperty(parameter)))
            return objectContract;

        // override default creation method to create object without constructor call
        objectContract.DefaultCreatorNonPublic = false;
        objectContract.DefaultCreator = () => FormatterServices.GetSafeUninitializedObject(objectContract.CreatedType);

        return objectContract;
    }
}

All you need is simply set this contract resolver in serializer settings before deserialization.

Update on readonly fields and get-only properties

A readonly field can be deserialized if it has a JsonProperty attribute applied. A get-only property can also be deserialized if it's backing field has a JsonProperty attribute applied. Since C# 7.3 it's possible to apply attributes to compiler-generated backing fields of auto-properties.

Leveraging this we could do something like this:

public class SampleClass
{
    [JsonProperty("Field1")]
    private readonly string _field1 = "Field1Value";

    [JsonProperty("Property1")]
    private string _property1BackingField = "Property1Value";

    [JsonIgnore]
    public string Property1 => _property1BackingField;

    [field: JsonProperty("Property2")]
    [JsonIgnore]
    public string Property2 { get; } = "Property2Value";
}

const string json = "{\"Field1\":\"NEW-Field1Value\",\"Property1\":\"NEW-Property1Value\",\"Property2\":\"NEW-Property2Value\"}";

var serializerSettings = new JsonSerializerSettings
{
    ContractResolver = new DefaultContractResolver
    {
        // this settings is needed to work with compiler-generated backing fields
        SerializeCompilerGeneratedMembers = true
    }
};

var deserializedSample = JsonConvert.DeserializeObject<SampleClass>(json, serializerSettings);

If you need to do this in older C# version or have no control over attributes, you could override CreateProperty() method of DefaultContractResolver with something like this:

protected override JsonProperty CreateProperty(MemberInfo member, MemberSerialization memberSerialization)
{
    var jsonProperty = base.CreateProperty(member, memberSerialization);

    if (jsonProperty.Writable == false)
    {
        // this uses compiler implementation details and may not work for all cases
        // better to use smarter approach like in BackingFieldResolver from Mono.Reflection library
        var fieldInfo = jsonProperty.DeclaringType.GetField($"<{jsonProperty.PropertyName}>k__BackingField",
            BindingFlags.NonPublic | BindingFlags.Instance);

        if (fieldInfo != null)
        {
            jsonProperty.ValueProvider = new ReflectionValueProvider(fieldInfo);
            jsonProperty.Writable = true;
        }
    }
        
    return jsonProperty;
}

The objectContract.OverrideConstructor property does not exists. — flayn, Nov 23 '21 at 15:00
@flayn Yes, it has been changed to OverrideCreator. I've updated the snippet. — Alexander, Jul 06 '22 at 07:50
@Alexander Do you know how you would expand on this to allow the deserialization process also write to readonly marked properties? — Erutan409, Nov 30 '22 at 22:11
@Erutan409 I've added ideas on readonly fields and get-only properties. Hope this helps. — Alexander, Dec 01 '22 at 08:26

How to deserialize class without calling a constructor?

4 Answers4

Linked