Can you explain the use case for this feature please?

The C# style guides/standards I've read in the past have all proscribed having members differentiated solely by case.

It's quite complexe but it can try to detailed my problem.

I use Json.Net to managed settings files used by my applications. These files should be mainly modiffied by my Apps but user can edit them manually.

I've one machine settings file and several user settings files. Machine settings file is not supposed to be editable. Only an administrator can distribute new machine settings files. Each modifications made by user are stores in user settings file and this file only contains "what is different" from machine file. User data takes precedence over machine ones.

To implement this, I've used JSon.Net JContainer.Merge and a custom umnmerged algo to separate "what is different". Merge/unmerge is done at json DOM level (ie tree of JObjects). On load, after merging machine and user data, I use Json.Net deserialization (JObject.ToObject) to get a strongly typed .Net settings object. On save, I get a JObject tree fromJToken.FromObject, do an unmerge (a deep clone and delete "what is identical") to only store differences in user settings. And all was good and well.

I've just had a subtle bug when customer a have manually edit settings file but have made a casing error (mimetype vs Mimetype). During merge/unmerge works on JObject tree, comparaisons are made case sensitives but deserialization not (GetClosestMatchProperty). This difference of treatment break my diff algo.

Also I need this feature.
I get sometimes very complex jsons with double names with only case sensitive difference (MyName is different from myName).
The thing is, I have no control over the stuff I get, and I only know what I need, so...
When I get the data, its get overridden by the data I don't care about :(

[Edit]

... It might be nice to see an easy way to configure it; but that might also bring in a strange contention between code depending on case, and code that doesn't.

I WAS very surprised because I simply passed a DataContract object to Cosmos, and got back asymmetric data. It happened to be the object ID, which was the most surprising point to discover that.

I am new, and I'll have to look more at configuration ... And sorry for the "opinion" --- I was taken by the thought of a "horizontal" shift with new transforms and handlers ... And so the thought of an "easy configuration" is still romantic for the new person here. ... So looking for the NamingStrategy to learn more for my own need.

PS: Newtonsoft is GREAT!

I would also like to push for this functionality. I had a pretty major logic issue where our object representation is different from the JObject representation, since it fudges the case sensitive property for the deserialization class. I want to avoid this and actually error out (or at the bare minimum not deserialize the property at all) when going from JSON to C# object.

It's currently impossible to override enough of a DefaultContractResolver to bypass the hardcoded JsonPropertyCollection.GetClosestMatchProperty functionality, so we are kinda stuck.

Hi, i would like to push for this as well. I'm trying to pass all tests on a conformance test suite.
Many of the tests include error handling when deserialization property names are case sensitive.
Has anyone found a way around this?

#1699 is the same feature request.

I also need this. I'm writing a validator for an API that will be consumed by a case-sensitive client.

A few years have passed. What reason not to do it so far?

I too need this, for creating a JSON:API implementation. According to the JSON:API specification, member names MUST be case sensitive. The lack of this feature means we already have clients using incorrect casing, violating the spec, but it's cumbersome to code around without being supported through Newtonsoft.Json.

Are there plans to fix this issue? I have plenty of API-tests in which I'd like to ensure, that my server will not change the case of serialized properties, after upgrading a library, changing some settings or changing to System.Text.Json.

Or is there a workarround, like creating a custom ContractResolver?

I think our best option is migration to System.Text.Json if possible. I dont see this changing anytime soon.

+1

System.text.json has better performance now!
see => https://dotnetcoretutorials.com/2020/01/25/what-those-benchmarks-of-system-text-json-dont-mention/

Can you explain the use case for this feature please?

The C# style guides/standards I've read in the past have all proscribed having members differentiated solely by case.

Future-proofing? I'm working on a project in which complex JToken queries are involved. We're looking to migrate from PascalCase to camelCase for our DTO properties. Taking backwards-compatibility into account, this is a blocking issue for us to accomplish without introducing our own shim.