Camel-cased property names + dictionary-as-object serialization = lossy conversion

[bwatts]

This issue started as a comment on the ASP.NET MVC issue concerning camel-casing of property names by default.

Below is a copy of the comment I left over there. Is this an issue that should be solved at the level of JSON.NET?

I just encountered an interesting scenario with camel-cased names and wanted to ensure we account for it.

The default serialization for a Dictionary<,> is to a JSON object:

{ "foo": "...", "bar": "..." }

However, if we serialize an upper-cased key Foo, it will become lower-cased as a property, then deserialize back with the lower-cased name, creating a lossy conversion.

We worked around this by creating a DictionaryConverter that treats dictionaries as List<KeyValuePair<K, V>>:

[
    { "key": "Foo", "value": "..." },
    { "key": "bar", "value": "..." }
]

We wanted to simply tell JSON.NET to use JsonArrayContract for dictionaries, but had to account for existing data that uses the object-not-array format.

[JamesNK]

Yes changing the dictionary key on serialization is lossy. That is by design. That is why I defaulted it to off with NamingStrategy. I believe it is also off by default with MVC Core.

[bwatts]

I thought so as well - I read through the source and indeed found the naming strategy bits.

However, here is .NET Fiddle with a reproduction (using Newtonsoft.Json 9.0.1)

Am I misinterpreting the results?

public static void Main()
{
    var x = new Dictionary<string, int>{ { "Foo", 1 }, { "Bar", 2 } };

    var settings = new JsonSerializerSettings();

    settings.ContractResolver = new CamelCasePropertyNamesContractResolver();

    Console.WriteLine(JsonConvert.SerializeObject(x, settings));
}

Results:

{"foo":1,"bar":2}

[bwatts]

It appears that CamelCasePropertyNamesContractResolver is simply not the right mechanism for my scenario, as it doesn't respect the dictionary key casing, while DefaultContractResolver has that capability.

I found this out from @khellang over on this thread, where he points out that MVC uses DefaultContractResolver with the CamelCaseNamingStrategy. I will move to using this now.

Given the unexpected effect of CamelCasePropertyNamesContractResolver in this context, and the fact that lossy dictionary conversions probably aren't a value-add, perhaps we could apply [Obsolete] to CamelCasePropertyNamesContractResolver?

[dougbu]

@bwatts CamelCasePropertyNamesContractResolver maintains its behaviour from earlier versions. That class explicitly overrides the DefaultContractResolver CamelCaseNamingStrategy defaults.

[JamesNK]

tl;dr; use CamelCaseNamingStrategy if you don't want dictionary keys touched.