In previous Newtonsoft.Json deserialization was case insensitive. But in System.Text.Json deserialization is case-sensitive which is forcing to write the following in every deserialization case:
JsonSerializerOptions jsonSerializerOptions = new JsonSerializerOptions()
{
PropertyNameCaseInsensitive = true
};
Please set the default value to true for PropertyNameCaseInsensitive in JsonSerializerOptions if there is no obvious reason to default value to false.
Thank you.
In previous
Newtonsoft.Jsondeserialization was case insensitive. But inSystem.Text.Jsonis deserialization case-sensitive which is forcing to write the following in every deserialization case:JsonSerializerOptions jsonSerializerOptions = new JsonSerializerOptions() { PropertyNameCaseInsensitive = true };Please set the default value to
trueforPropertyNameCaseInsensitiveinJsonSerializerOptionsif there is no obvious reason to default value to false.Thank you.
It looks like a good setting by default.
This difference is intentional and documented. See https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to#case-insensitive-deserialization for further information.
The
System.Text.Jsondefault is case-sensitive, which gives better performance since it's doing an exact match.
Don't know how much performance gain it will give but in almost every cases we need case insensitive deserialization because naming convention in JSON and C# are not same.
This would be breaking for anyone that depends on the default behavior.
There's an open issue to provide a way to set/change the default serializer options - https://github.com/dotnet/runtime/issues/31094. This will allow you to set the PropertyNameCaseInsensitive option only once.
Closing as a duplicate of https://github.com/dotnet/runtime/issues/31094.
This would be breaking for anyone that depends on the default behavior.
Why it would break for anyone that depends on the default behavior(false)? Case insensitive means it would map irrespective of case sensitivity. That's means current default behavior (false) is included here anyway.
Why it would break for anyone that depends on the default behavior(false)?
Today's default behavior means that the entry ends up in the generated object's overflow bag. With your proposed change the entry would no longer end up in the overflow bag. That is a breaking change.
Even if it is a breaking change, I'd argue it is a valid one for a major version change. Specially if the possibility of setting it only once in the code is made available (as said above).
If the majority of your users have to change the default setting, then the default is wrong, not the users.
Most helpful comment
Even if it is a breaking change, I'd argue it is a valid one for a major version change. Specially if the possibility of setting it only once in the code is made available (as said above).
If the majority of your users have to change the default setting, then the default is wrong, not the users.