Develop Reference

Why does JsonConvert treat default constructors and parameterized constructors differently?

I was trying out Json.net's ability to serialize and deserialize dictionaries, and thanks to this post I was able to find a good solution to serializing dictionaries in a simple way.
It was working great, but in a certain circumstance it broke in a (to me) nonsensical way such that I couldn't help but spend the next three hours debugging.
Here is the problem. When serializing this class
public class ReferenceTesting
{
public List<Scenario> scenarios = new List<Scenario>();
private Dictionary<Scenario, float> _Dict = new Dictionary<Scenario, float>();
[JsonProperty]
public List<KeyValuePair<Scenario, float>> SerializedDict
{
get { return _Dict.ToList(); }
set { _Dict = value.ToDictionary(x => x.Key, x => x.Value); }
}
public ReferenceTesting(int number = 0)
{
for (int i = 0; i < number; i++)
{
Scenario s1 = new Scenario();
scenarios.Add(s1);
_Dict.Add(s1, i);
}
}
public override string ToString()
{
string s = "";
for (int i = 0; i < scenarios.Count(); i++)
{
Scenario scenario = scenarios[i];
s += $"scenario{i} \n";
}
foreach (KeyValuePair<Scenario, float> scenario in SerializedDict)
{
s += $"Key: {scenario.Key}, Value: {scenario.Value} \n";
}
return s;
}
}
Everything works as expected, meaning when I instantiate
new Reference(3);
and then serialize and deserialize, I end up with an object with as expected 3 items in the list, and 3 items in the dictionary.
Output:
scenario0
scenario1
scenario2
Key: Scenario, Value: 0
Key: Scenario, Value: 1
Key: Scenario, Value: 2
However, by adding the default constructor
public ReferenceTesting() { }
the serialization works, writing out 3 items in list and dictionary, but deserialization does not work with the property. Meaning I end up with
scenario0
scenario1
scenario2
as output.
The big surprise with this is that the two constructors do the exact same thing - which is nothing when number = 0 (which it is when Json.net creates it, I doublechecked). So this means that the serializer has to be doing something under the hood to treat the property differently if there is or is not a default constructor.

How does Json.NET deserialize an object differently when it has a parameterized constructor vs. when it has a default constructor?
Json.NET is a streaming deserializer. Whenever possible it deserializes as it streams through the JSON rather than preloading the complete JSON into an intermediate representation before final deserialization.
Thus, when deserializing a JSON object with a default constructor, it first constructs the corresponding .Net object. It then recursively populates the object's .Net members by streaming through the key/value pairs in the JSON until the end of the JSON object. For each pair encountered, it finds the corresponding .Net member. If the value is a primitive type, it deserializes the primitive and sets the value. But if the value is a complex type (JSON object or array) it constructs the child object if necessary, sets the value back in the parent, and then populates it recursively as it continues to stream.
However, when deserializing an object with a parameterized constructor, Json.NET cannot use this streaming algorithm and instead must first fully deserialize the JSON object to an intermediate table of deserialized .Net name/value pairs, matching each JSON value to its corresponding .Net constructor argument or property by name and then deserializing to the type declared in .Net. Only then can the object be constructed by passing the deserialized constructor parameters into the constructor, and setting the remainder as property values.
For details on this process, see
JSON.net: how to deserialize without using the default constructor?
How does JSON deserialization in C# work.
(There is a third algorithm for ISerializable objects which does not apply in your case.)
Why is my surrogate public List<KeyValuePair<Scenario, float>> SerializedDict property not deserialized correctly when deserializing via a default constructor?
The reason is explained in this answer to Why are all the collections in my POCO are null when deserializing some valid json with the .NET Newtonsoft.Json component, and arises about of the specifics of Json.NET's Populate() algorithm:
It calls the getter in the parent class to get the current value of the property being deserialized.
If null, and unless a custom constructor is being used, it allocates an instance of the property's returned type (using the JsonContract.DefaultCreator method for the type).
It calls the setter in the parent to set the allocated instance back into the parent.
It proceeds to populate the instance of the type.
It does not set the instance back a second time, after it has been populated.
Thus the setter for SerializedDict is not called after the list is populated.
But when the parent class has a parameterized constructor, the property value SerializedDict is fully deserialized before its parent is constructed, so the setter is called with a fully populated surrogate list.
How can I create a surrogate collection property that works in both scenarios?
You can use an array instead of a list. Since an array cannot be resized, it must be fully deserialized and populated before it can be set back in the parent object:
public class ReferenceTesting
{
public KeyValuePair<Scenario, float> [] SerializedDict
{
get { return _Dict.ToArray(); }
set { _Dict = value.ToDictionary(x => x.Key, x => x.Value); }
}
// Remainder unchanged
You could make the array property be private if you want, by marking it with [JsonProperty].
By the way, your current deserialization creates duplicate Scenario objects in the scenarios and _Dict collections as shown by demo fiddle #1 here.
One way to fix this would be to serialize just _Dict (assuming that all scenarios are in the dictionary). Another would be to use PreserveReferencesHandling, e.g. by adding [JsonObject(IsReference = true)] to Scenario:
[JsonObject(IsReference = true)]
public class Scenario
{
// Remainder unchanged
}
Notes:
There is no standard for serialization of references in JSON. Json.NET's implementation may not match that of other serializers.
PreserveReferencesHandling doesn't work for objects with parameterized constructors (see here for details), so make sure Scenario doesn't have one.
Demo fiddle #2 here showing everything working correctly with a default constructor, and #3 here with a parameterized constructor.

Serialize json value types with type data

I've almost solved my problem but missing the last piece...
I Have a list of object and I want to be able to add value types (that normaly will be serialized to strings) and get them back as the original type.
For example: Guids or custom value types.
This is a sample custom value type:
public struct ExtString
{
private String Value
{
get;
set;
}
public static implicit operator ExtString(String str)
{
return !String.IsNullOrWhiteSpace(str) ? new ExtString(str) : null;
}
public static implicit operator String(ExtString exStr)
{
return exStr.ToString();
}
public ExtString(String str)
{
this.Value = str;
}
public override String ToString()
{
return this.Value;
}
}
This is the Custom converter:
public class CustomConverter : JsonConverter
{
public override Boolean CanConvert(Type objectType)
{
return objectType.IsValueType;
}
public override bool CanRead => false;
public override void WriteJson(JsonWriter writer, Object value, JsonSerializer serializer)
{
writer.WriteStartObject();
writer.WritePropertyName("$type");
writer.WriteValue(value.GetType().AssemblyQualifiedName);
writer.WritePropertyName("$value");
writer.WriteValue(value.ToString());
writer.WriteEndObject();
}
And here is the sample code for serializing / deserilizing:
var jsonSerializerSettings = new JsonSerializerSettings()
{
TypeNameHandling = TypeNameHandling.All,
Converters = new JsonConverter[]
{
new CustomConverter()
}
};
var list = new List<Object>();
list.Add(Guid.NewGuid());
list.Add((ExtString)"Hello World");
var ser = JsonConvert.SerializeObject(list, Formatting.Indented, jsonSerializerSettings);
var deser = JsonConvert.DeserializeObject(ser, jsonSerializerSettings);
This works almost all the way... Both the Guid and ExtString is serialized correct and the Guid is even deserialized with correct value (without special handling!), and the ExtString is created correct (on deserialize) but with the value null (constructor is called but str is null).
What am I missing? Why does it work for Guid?
Thanks.

All you have to do is to specify the JSON property name for your Value property.
public struct ExtString
{
[JsonProperty("$value")]
private String Value
{
...
More in depth
The Guid mapping works because it is considered a primitive type and Json.Net knows how to create a new instance and the parameter to pass to (using a JsonPrimitiveContract).
On the contrary, ExtString is resolved using a JsonObjectContract which calls the parameterless constructor of ExtString (it is there even if you don't declare it, because it's a value type) and then assigns the properties values to the corresponding json properties values. But the ExtString struct property name is Value while the JSON property name is $value. So a new istance of ExtString is created but the Value property remains null because there aren't properties with name Value. This is why, in your code, you have a new istance of ExtString with the Value property setted to null.
In the above solution I match the property name of the ExtString struct with the name of the property in the input JSON. After creating an instance of the ExtString struct, a mapping of the $value property will be done with success.
Another solution could be:
public struct ExtString
{
private String Value
{
get;
set;
}
[JsonConstructor]
public ExtString([JsonProperty("$value")] String str)
{
this.Value = str;
}
In this case, the constructor with the JsonConstructor attribute will be used instead of the parameterless one. Note that the str parameter must be provided with the appropriate JsonProperty attribute which defines the property name (in the input JSON) whose value will be passed to the constructor. If you omit the JsonProperty attribute, str parameter will be null and so your Value property too.
The difference between the two solutions is on the where the Value property is assigned. In the first solution the property is assigned after creating the object, in the second solution the property is assigned by the constructor.
Think it in this way:
//First solution
var myObject = new ExtString();
myObject.Value = "Hello World";
//Second solution
var myObject = new ExtString("Hello World");
I think the first solution give you much more control setting the value because (modifing the setter method) your logic will be always called, no matter how you create the object or when you assign the value.
Source: a pleasant and immersive analysis of the source code.
I know, my English is very bad :)

Modify/Add property via custom IContractResolver

I have a class:
public class MyClass
{
public MyEnum Foo{ get; set; }
}
During serialization i'd like to change the output from
{
"Foo": 1
}
to
{
"Foo": "EnumName"
}
I've tried creating an IValueProvider but hit dead ends every way I go. (My scenario is a bit more complicated than stated; I need to find a way to do this entirely within the IContractResolver.)

You could create a custom ContractResolver inheriting from DefaultContractResolver that automatically applies StringEnumConverter to every contract for an enum or nullable enum:
public class StringEnumContractResolver : DefaultContractResolver
{
readonly StringEnumConverter converter;
public StringEnumContractResolver() : this(true, false) { }
public StringEnumContractResolver(bool allowIntegerValue, bool camelCaseText)
{
this.converter = new StringEnumConverter { AllowIntegerValues = allowIntegerValue, CamelCaseText = camelCaseText };
}
protected override JsonPrimitiveContract CreatePrimitiveContract(Type objectType)
{
var contract = base.CreatePrimitiveContract(objectType);
var type = Nullable.GetUnderlyingType(contract.UnderlyingType) ?? contract.UnderlyingType;
if (type.IsEnum && contract.Converter == null)
contract.Converter = converter;
return contract;
}
}
Notes:
If the enum type already has a JsonConverter applied, that is kept in preference to the default StringEnumConverter.
Adding the converter to the JsonPrimitiveContract for the enum itself, rather than to every JsonProperty for members that return the enum, ensures that the converter is applied to enums in collections and dictionaries.
The IValueProvider merely provides methods to get and set values and thus is less convenient to this purpose than the converter. You would need to perform a nested serialization and deserialization of the enum value as a JSON string inside it, but it isn't designed for this and so doesn't have access to the JSON reader, writer, or serializer. In addition, there is no value provider for dictionary values or collection items that are enums.
You may want to cache the contract resolver for best performance as explained here.
Sample .Net fiddle.

Conditional serialization/deserialization of object properties with json.net [duplicate]

This question already has answers here:
Serialize Property, but Do Not Deserialize Property in Json.Net
(2 answers)
Closed 6 years ago.
I have a scenario with a class defined as below:
class MyObject
{
public DataDictionary MyObjectData { get; set; }
public bool ShouldSerializeMyObjectData() { return true; }
public bool ShouldDeserializeMyObjectData() { return false; }
}
When I attempt to serialize/deserialize that class with JSON.net, it takes the ShouldSerialize into account, but not the ShouldDeserialize.
According to the documentation, both should work the same way I guess. Is there something particular I should know? More generally, how should I deal with scenarios where I want to serialize a property but not deserialize it?
I'm using Json.NET 8.0 if that matters.
Thanks for your help.

The short answer to your question is, automatically checking for ShouldDeserialize{PropertyName}() is not currently implemented even though ShouldSerialize{PropertyName}() is. A longer answer and workaround follow.
The class JsonProperty is used internally by Json.NET to define a contract for how to map a JSON property to a .NET member or constructor parameter. It has two predicate properties, ShouldSerialize and ShouldDeserialize that, when non-null, prevent a property from being serialized and deserialized, respectively. Initializing each JsonProperty is the job of the ContractResolver. For each property {PropertyName}, Json.NET's default contract resolver automatically checks for the presence of a public bool ShouldSerialize{PropertyName}() method. If such a method exists, it adds a call to it in the ShouldSerialize predicate, thereby suppressing serialization when the method returns false. This was implemented because controlling property serialization via a method ShouldSerialize{PropertyName}() is a standard pattern supported by, e.g., XmlSerializer. For more background see the relevant Json.NET release notes.
For example, in the following class, serialization of MyObjectData will be suppressed unless MyObjectData.Count > 0:
class MyObject
{
public DataDictionary MyObjectData { get; set; }
public bool ShouldSerializeMyObjectData() { return MyObjectData != null && MyObjectData.Count > 0; }
}
JsonProperty.ShouldDeserialize, however, it is never set by the default contract resolver. This may be due to the fact that there is no standard pattern for deserialization equivalent to ShouldSerialize{PropertyName}() and so Newtonsoft never had any requests to implement such a pattern. Nevertheless, as you have noticed, infrastructure to support such a pattern exists, and so applications can create custom contract resolvers that do just that. In fact, Json.NET has an example of such a contract resolver in its own test suite:
public class ShouldDeserializeContractResolver : DefaultContractResolver
{
public static new readonly ShouldDeserializeContractResolver Instance = new ShouldDeserializeContractResolver();
protected override JsonProperty CreateProperty(MemberInfo member, MemberSerialization memberSerialization)
{
JsonProperty property = base.CreateProperty(member, memberSerialization);
MethodInfo shouldDeserializeMethodInfo = member.DeclaringType.GetMethod("ShouldDeserialize" + member.Name);
if (shouldDeserializeMethodInfo != null)
{
property.ShouldDeserialize = o => { return (bool)shouldDeserializeMethodInfo.Invoke(o, null); };
}
return property;
}
}
public class ShouldDeserializeTestClass
{
[JsonExtensionData]
public IDictionary<string, JToken> ExtensionData { get; set; }
public bool HasName { get; set; }
public string Name { get; set; }
public bool ShouldDeserializeName()
{
return HasName;
}
}
If you want to conditionally suppress deserialization of properties even when present in the JSON, you may use this contract resolver.
Notes:
If you do use a custom contract resolver, you should cache and reuse it for best performance.
JsonProperty.ShouldDeserialize is called before the property value is deserialized. If it returns true, the property is skipped, with no ability to examine the contents of the property. Thus it cannot be used to implement custom filtering based on that value.
A JSON object is defined by the JSON standard as an unordered set of name/value pairs. Thus a ShouldDeserialize method that assumes that other properties have already been read in may be brittle.
Instead, if you want to skip deserialization of one property based on the value of another, consider using an [OnDeserialized] callback and clearing the unwanted value there, after all properties have been deserialized.

How to serialize class type but not the namespace to a Json string using DataContractJsonSerializer

I'm trying to serialize a class hierarchy to a Json string using DataContractJsonSerializer, in a WCF service.
the default behaviour for serializing a derived class is to add the following key value pair to the object:
"__type":"ClassName:#Namespace"
My problem is that namespaces are long and they bloat the Json string.
I would like to somehow intervene with the serialization and output this instead:
"__type":"ClassName"
and on deserialization intervene again to point to the correct namespace (which i know in runtime).
Is there any way to do such a thing?

This page describes the circumstances under which the __type property is emitted. In short, in WCF, if you use a derived type, and a KnownTypeAttribute, then you're going to get a __type property.
Example:
Assume
[DataContract]
[KnownType(typeof(Subscriber))]
public class Person { ... }
[DataContract]
public class Subscriber : Person { ... }
This code generates a __type property:
var o = new Subscriber("Fleming");
var serializer = new DataContractJsonSerializer(typeof(Person));
serializer.WriteObject(Console.OpenStandardOutput(), o);
But this code does not:
var o = new Subscriber("Fleming");
var serializer = new DataContractJsonSerializer(typeof(Subscriber));
serializer.WriteObject(Console.OpenStandardOutput(), o);
Notice that the second snip uses a DCJS with the same type as the object being serialized.
To avoid the __type, don't use derived types, or to be precise, use a serializer typed to the type you are actually serializing. If the serialization is being performed implicitly by a WCF method, then the method must be typed appropriately. In my example, it means you must use a return type of "Subscriber", and not the parent type, "Person".
The __type is emitted into the JSON stream by the (private) WriteServerTypeAttribute method on the
(internal) System.Runtime.Serialization.Json.XmlJsonWriter class. There is no public, documented, supported way to modify that, as far as I can tell.
To avoid this, you'd maybe need to return a string from the WCF method, perform the serialization yourself, and post-process the emitted JSON.
If you don't mind the __type thing, but just want to remove the qualifying namespace from the value, then put your types in the global namespace. In other words, put them outside of any namespace declaration in code.
Example: When the data types reside in a namespace, and when I used a derived type, the serialized JSON looks like this:
{
"__type":"Subscriber:#My.Custom.Namespace",
"Index":604455,
"Name":"Fleming",
"Id":580540
}
When the data types reside in the global namespace, it looks like this:
{
"__type":"Subscriber:#",
"Index":708759,
"Name":"Fleming",
"Id":675323
}

Adding the namespace parameter to the data contract does the trick.
[DataContract(Namespace = "")]

Cheeso's answer was excellent. I did discover a refinement to cleaning up the __type field though:
Rather than removing your subclass from its namespace you can add a property like the following:
[DataMember(Name = "__type")]
public string SubclassType
{
get
{
return "Subscriber";
}
set { }
}
You still get stuck with the ugly name "__type" but I found that because I was returning a list of subtypes I wanted to specify the type name anyway. You could even return a value of "" to further reduce response size. You could also just declare the property as:
public string __type
but I found that to accentuate the hack so I stuck with an appropriate property name and then renamed it.
-Joey

Note: I typed up this answer below and later realized that DataContractResolver is currently not supported with DataContractJsonSerializer. It may soon be with the next release of the framework, however. This is also useful if you are looking at more than just JSON.
**
You can do this with a DataContractResolver, which lets you map types to xsi:type (__type) information and vice-versa in a custom manner.
To do this, check out this blog post on DataContractResolver, plus this conceptual topic, plus this sample

#Cheeso wrote:
To avoid this, you'd maybe need to return a string from the WCF
method, perform the serialization yourself, and post-process the
emitted JSON.
Here's how I implemented that post-processing. I thought I'd post it here JIC it might help someone else.
First some boilerplate to show how I generate my JSON string:
// Instantiate & populate the object to be serialized to JSON
SomeClass xyz = new SomeClass();
... populate it ...
// Now serialize it
DataContractJsonSerializer ser = new DataContractJsonSerializer(xyz.GetType()); // Note xyz.GetType()
... serialize the object to json, many steps omitted here for brevity ...
string json = sr.ReadToEnd();
(Serialization is based on examples from https://msdn.microsoft.com/en-us/library/bb412179%28v=vs.110%29.aspx )
Note that the [DataContract] on SomeClass does not include the (name="") syntax that I've seen suggested elsewhere. That only removes the namespace from the __type at the cost of needing to adorn ALL your DataContract attrs, which clutters your code. Instead, my post-processor handles the assembly name in the __type field.
And now the string json contains the JSON text, but unfortunately includes all that "__type" junk that you don't want but can't suppress.
So here's my post-processing code that removes it:
// This strips out that unsuppressable __type clutter generated by the KnownType attributes
Attribute[] attrs = Attribute.GetCustomAttributes(xyz.GetType());
foreach (Attribute attr in attrs)
{
if (attr is KnownTypeAttribute)
{
KnownTypeAttribute a = (KnownTypeAttribute)attr;
string find = "\"__type\":\"" + a.Type.ReflectedType.Name + "." + a.Type.Name + ":#" + a.Type.Namespace + "\",";
json = json.Replace(find, "");
}
}
This makes a few assumptions, most notably that the __type field ends with a comma, which assumes that another field follows it, though (a) my objects always have at least 1 field and (b) I've found that the __type field is always 1st in the serialized object's output.
As always, you may have to adjust something to your situation, but I find it works well for mine.

Some times ago i decided this problem.
I use DataContractJsonSerializer
You will have __type in json, if your method for serialization have Base class parameter, but you give it subClass as parameter.
More details:
[DataContract]
[KnownType(typeof(B))]
public abstract class A
{
[DataMember]
public String S { get; set; }
}
[DataContract]
public class B : A
{
[DataMember]
public Int32 Age { get; set; }
}
public static String ToJson<T>(this T value)
{
var serializer = new DataContractJsonSerializer(typeof(T));
using (var stream = new MemoryStream())
{
serializer.WriteObject(stream, value);
return Encoding.UTF8.GetString(stream.ToArray());
}
}
You have two methods for test:
public static void ReadTypeDerived(A type)
{
Console.WriteLine(ToJson(type));
}
and
public static void ReadType<T>(T type)
{
Console.WriteLine(ToJson(type));
}
In first test you wiil have
"{\"__type\":\"B:#ConsoleApplication1\",\"S\":\"Vv\",\"Age\":10}"
In second:
"{\"S\":\"Vv\",\"Age\":10}"