Json.NET is a popular high-performance JSON framework for .NET

We're using Json.NET 8.0.2 in a C# 4.5 project, and we love it.

However this behavior bit us pretty hard:

var obj = JsonConvert.DeserializeObject<JObject>("{ 'x': '2016-03-31T07:02:00+07:00' }");

Here, in our time zone, ob["x"].Value<string>() returns "2016-03-31T02:02:00+02:00".

The problem disappears if we specify how to parse dates:

var obj = JsonConvert.DeserializeObject<JObject>("{ 'x': '2016-03-31T07:02:00+07:00' }",
    new JsonSerializerSettings() { DateParseHandling = DateParseHandling.None });

But I find it dangerously surprising that by default Json.NET interprets strings as dates (let alone the performance issues this inevitably brings with it).

Is this the expected behavior? If so, is there a way to disable this behavior globally?

We all love the lib, but we all don't like having a browser open every time we do a package install. It's borderline obnoxious. Thank you.

JSON.NET currently has PCL folder that targets portable-net45+wp80+win8+wpa81+dnxcore50 this works for older PCL projects and .NET Framework based projects because msbuild adds all of the facades to the compiler target. Moving forward, that's no longer the case. Instead packages are expected to specify what dependencies they use in the nuspec.

Here' an example of System.Collections.nuspec:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/01/nuspec.xsd">
  <metadata minClientVersion="3.0">
    <id>System.Collections</id>
    <version>4.0.10-beta-23110</version>
    <title>System.Collections</title>
    <authors>Microsoft</authors>
    <owners>microsoft,dotnetframework</owners>
    <licenseUrl>http://go.microsoft.com/fwlink/?LinkId=329770</licenseUrl>
    <iconUrl>http://go.microsoft.com/fwlink/?LinkID=288859</iconUrl>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <description>Provides classes that define generic collections, which allow developers to create strongly typed collections that provide better type safety and performance than non-generic strongly typed collections.

Commonly Used Types:
System.Collections.Generic.List&lt;T&gt;
System.Collections.Generic.Dictionary&lt;TKey, TValue&gt;
System.Collections.Generic.Queue&lt;T&gt;
System.Collections.Generic.Stack&lt;T&gt;
System.Collections.Generic.HashSet&lt;T&gt;
System.Collections.Generic.LinkedList&lt;T&gt;
System.Collections.Generic.EqualityComparer&lt;T&gt;
System.Collections.Generic.Comparer&lt;T&gt;
System.Collections.Generic.SortedDictionary&lt;TKey, TValue&gt;</description>
    <copyright>© Microsoft Corporation.  All rights reserved.</copyright>
    <dependencies>
      <group targetFramework="MonoAndroid1.0" />
      <group targetFramework="MonoTouch1.0" />
      <group targetFramework=".NETFramework4.6" />
      <group targetFramework="Xamarin.iOS1.0" />
      <group targetFramework="Xamarin.Mac2.0" />
      <group targetFramework=".NETPlatform5.0">
        <dependency id="System.Runtime" version="4.0.0" />
      </group>
      <group targetFramework=".NETCore5.0">
        <dependency id="System.Runtime" version="4.0.20-beta-23110" />
        <dependency id="System.Resources.ResourceManager" version="4.0.0-beta-23110" />
        <dependency id="System.Diagnostics.Debug" version="4.0.0" />
        <dependency id="System.Threading" version="4.0.0" />
        <dependency id="System.Runtime.Extensions" version="4.0.0" />
      </group>
      <group targetFramework="DNXCore5.0">
        <dependency id="System.Runtime" version="4.0.20-beta-23110" />
      </group>
    </dependencies>
  </metadata>
</package>

Notice that the dependencies are specified in the TFM specific group. That's what JSON.NET should do for .NET Core based platforms. Here's the recommended solution, remove +dnxcore50 from the PCL folder, make a new folder called dotnet and put the dll in there. Specify the dependencies you use in your nuspec with a dependency group targeting dotnet/aka .NETPlatform5.0

Getter-only properties in C# are readonly, but they should still be deserialized.

I.e. this does not work (but should) (Tested in v6.0.8):

public class MyClass
{
    public string MyProp { get; }
}

...

var r = JsonConvert.DeserializeObject<MyClass>("{\"MyProp\":\"awesome\"}");

Assert.AreEqual("awesome", r.MyProp);

However, changing the class to this makes it all work:

public class MyClass
{
    public string MyProp { get; private set; }
}

These two classes should work the same.

Hi,

When do you expect to support the Json Schema Specification (Version 4)?

Contributes to #650

Extracted from #1119 but only covering the async methods on JsonReader and JsonWriter and implementation for JsonTextReader and JsonTextWriter.

We are requesting a feature flag to disable the new behavior consisting of copying annotations when cloning tokens. Previous behavior allowed users the option to copy annotations when necessary and skip this step otherwise.

Here is the commit containing the change we hope to disable: https://github.com/JamesNK/Newtonsoft.Json/commit/ff5ffb2832b2297502d1ff44efb2e16c57a648b7

This PR aims to address #815, by implementing a new serializer option, named PropertyCaseSensitivityHandling:

public enum PropertyCaseSensitivityHandling
{
    // Case-insensitive matching (default).
    CaseInsensitive = 0,

    // Case-sensitive matching.
    CaseSensitive = 1
}

To preserve continuity with prior implementations, default is set to CaseInsensitive. With the new behaviour provided by CaseSensitive, we can now have differentiation and validation for casing, which is required by several API specs (Binance & xAPI, to name a few examples).

As this behaviour has an extremely lightweight implementation (only one extra check on each Property matching), it does what it says on the tin, and only that.

Most of the matching with convention-following PascalCase C# properties will fail if you don't add [JsonProperty("name")] to each property, or write some esoteric conversion between JSON standard camelCase (or whichever casing is used) and C# Properties.

---

A few footnotes...

This PR was inspired by the stale #601, where I factually stripped the Casing implementation to form my own. Furthermore, as this is my first ever PR to Newtonsoft.Json (hello guys!), I might've inadvertently broken a few long-standing conventions along the way, so any feedback will be most appreciated.

We're hitting an issue in production after a 13.0.1 upgrade unable to deserialize JSON. Though the actual code involved JToken.ToObject<T>() the repro is the same with a simplified JsonConvert.DeserializeObject<T>() so using that below. I've tested this scenario and our code is working up through 12.0.3 but it breaks in 13.0.1 and I can't find any release notes or issues that seem to be the cause.

Full repro

void Main()
{
    string json = @"
{
  ""Name"": ""MyName"",
  ""ChildClassProp"": ""MyValue"",
}";

    // JsonSerializationException: 
    // Unexpected token when deserializing object: String. Path 'ChildClassProp', line 4, position 29.
    JsonConvert.DeserializeObject<MyRecord>(json);
}

[DataContract]
public abstract class RecordBase
{
    [JsonExtensionData]
    protected IDictionary<string, JToken> additionalData;

    public string Name { get; set; }
}

[DataContract]
public class MyRecord : RecordBase
{    
    public MyRecord(string childClassProp) => ChildClassProp = childClassProp;
    
    [DataMember]
    public string ChildClassProp { get; set; }
}

I have found that removing [JsonExtensionData] (needed for round-tripping) makes it behave as expected as does adding a default constructor to the MyRecord class (which would be a large number of locations and not desirable in the codebase). It also works adding a [DataMember] to Name in the base class (which makes sense, but the behavior change has broken us so filing here!)

I can also more minimally repro (left above in case base is important):

[DataContract]
public class MyRecord
{
    public MyRecord(string _) {}

    [JsonExtensionData]
    protected IDictionary<string, JToken> additionalData;

    public string Name { get; set; }
}

Perhaps it can't tell without the [DataMember] on Name which items should be in the extension data? Hazarding a guess here.

Expected behavior

Deserialization to work as it did in <= 12.0.3, producing a populated MyRecord.

Actual behavior

Exception when calling JsonConvert.DeserializeObject<MyRecord>(json):

JsonSerializationException: Unexpected token when deserializing object: String. Path 'ChildClassProp', line 4, position 29.

cc @glennamanns

"41 lines (32 sloc) 1.35 KB Get Access Token From App Canvas Example This example covers obtaining an access token and signed request from within the context of an app canvas with the Facebook SDK for PHP.

Example A signed request will be sent to your app via the HTTP POST method within the context of app canvas. The PHP SDK provides a helper to easily obtain, validate & decode the signed request. If the proper OAuth data exists in the signed request payload data, an attempt can be made to obtain an access token from the Graph API.

$fb = new Facebook\Facebook([ 'app_id' => '{app-id}', 'app_secret' => '{app-secret}', 'default_graph_version' => 'v2.10', ]);

$helper = $fb->getCanvasHelper();

try { $accessToken = $helper->getAccessToken(); } catch(Facebook\Exceptions\FacebookResponseException $e) { // When Graph returns an error echo 'Graph returned an error: ' . $e->getMessage(); exit; } catch(Facebook\Exceptions\FacebookSDKException $e) { // When validation fails or other local issues echo 'Facebook SDK returned an error: ' . $e->getMessage(); exit; }

if (! isset($accessToken)) { echo 'No OAuth data could be obtained from the signed request. User has not authorized your app yet.'; exit; }

// Logged in https://m.facebook.com/login/?refsrc=deprecated&_rdr echo '

Signed Request

'; var_dump($helper->getSignedRequest());

echo '

Access Token

'; var_dump($accessToken->getValue())" https://gist.githubusercontent.com/abc471/0b8a1ed9567deff23d0fbd6d3962949c/raw/1a5056c825cbf86dbbe24da874e85152707265c6/Facebook#:~:text=41%20lines%20(32,var_dump(%24accessToken%2D%3EgetValue())

Source/destination types

enum TestProp { Value1 }

class TestClass
{
    public TestProp TestProp => Child.TestProp;
    public TestChildClass Child { get; set; }
}

class TestChildClass
{
    public TestProp TestProp { get; set; } = TestProp.Value1;
}

Source/destination JSON

{"TestProp":"Value1","Child":{"TestProp":"Value1"}}

Expected behavior

The two tests in the "steps to reproduce" section should pass.

Actual behavior

However It_should_serialize_prop_with_custom_getset fails with the error:

System.NullReferenceException: 'Object reference not set to an instance of an object.'

TestClass.Child.get returned null.

There seems to be a problem with using the StringEnumConverter with an expression-bodied member. The first test below fails but the second one passes.

Steps to reproduce

[Fact]
public void It_should_serialize_prop_with_custom_getset()
{
    var testClass = new TestClass { Child = new TestChildClass() };
    var settings = new JsonSerializerSettings { Converters = new List<JsonConverter> { new StringEnumConverter() } };
    var json = JsonConvert.SerializeObject(testClass, settings);
    // Test fails on the line below.
    var result = JsonConvert.DeserializeObject<TestClass>(json, settings);
}

[Fact]
public void It_should_serialize_prop_with_custom_getset_no_settings()
{
    var testClass = new TestClass { Child = new TestChildClass() };
    var json = JsonConvert.SerializeObject(testClass);
    // No issues if we don't use a `StringEnumConverter`.
    var result = JsonConvert.DeserializeObject<TestClass>(json);
}

Source/destination types

For example string to int

Source/destination JSON

    { "income": "alert(99599)" }

Expected behavior

It would be nice to have the option via JsonSerializerSettings to control if input data is echoed back in error messages. In the example above if input echoing was disabled then the message would be something like "message": "Could not convert string to integer. Path 'applicant_details.income', line 1, position 404."

Actual behavior

Currently the original input is echoed back which could leave a (badly written) website at risk of script injection attacks "message": "Could not convert string to integer: alert(99599). Path 'applicant_details.income', line 1, position 404."

Steps to reproduce

Utilising Json.NET via AspNetCore MVC
services.AddMvc()
            .AddNewtonsoftJson(.....)