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.

New methods that catch exception from the original JObject.Parse(...) method and return false, otherwise returns true and output the result JObject.

public partial class JObject {
+  public static bool TryParse(string json, out JObject? jObject)
+  public static bool TryParse(string json, JsonLoadSettings? settings, out JObject? jObject)
}

public partial class JToken{
+  public static bool TryParse(string json, out JToken? jToken)
+  public static bool TryParse(string json, JsonLoadSettings? settings, out JToken? jToken)
}

Source/destination types

string userdetail = "{\"username\":\"john\"}";
LogInData logindata = JsonConvert.DeserializeObject<LogInData>(userdetail);

Source/destination JSON

{"username":"john"}

Expected behavior

Nothing happened

Actual behavior

I got [libc] Requested dump for tid xxxx (com.xxx.xxxx) at the console log. At the app debug, I got error message saying the app has hang and do I wanted to wait or not.

Debugging Environment

I am debugging with AMD Ryzen 1700 with 32GB of RAM on an Android emulator (R11.0 - API 30) on VS2019 (Version 16.10.0).

However, when I moved the debugging to another machine, Intel i9, same Android emulator, same VS2019 version. There is no such error in the emulator. Only the particular JsonConvert.DeserializeObject has this issue. I cannot seems to find where is the error here except having different processor. I will share my solution later today. So see if anyone can replicate with an AMD processor.

The following sample is generated in .NET Core 3.1 environment.

I am trying to serialize a List that contains elements of type double.

To keep things simple I am specifying just a couple of values. Source

0.99470101959419988 6.2202183684300157E-11

Expected behavior

0.99470101959419988 6.2202183684300157E-11

Actual behavior

0.9947010195941999 6.220218368430016E-11

I have already tried this solution https://github.com/JamesNK/Newtonsoft.Json/issues/2537 but it doesn't seem to work for my case.

Think I found an issue, so cloned the repo and created some tests to verify and also started on a solution, but since I'm not that familiar with the Newtonsoft.Json code (or contributing to open source :) I'm really unsure how to move forward...

Can I ask questions here on if my / what solution is the right path? I don't want to break other things!

The problem: When deserialize an object where a property is a value type (eg. string, int, bool) but in the json string is an object there will of course be an exception (invalid char '{' found). But if you then add an error handling (ErrorContext.Handled = true) the exception correctly will be suppressed, but the JsonTextReader has already moved past the '{' so when the internal error handling calls Skip() the state will be Property instead of ObjectStart and the skip will not function as supposed.

I'm thinking that how the JsonTextReader behaves on exception might be wrong. Should it not return to the position where it started reading when an error occurs? Because now I even think that the error message gives the wrong position index...?

I tested this and it fixes my issue but breaks a couple of other test, one regarding the position in error message and it also breakes Skip() in the way that if an error occurs in Skip() the reader will never past by since the buffer position will return to before the error. This is because the Skip() actually is a Read() that throws on errors(?)

Any help from some one with more insight in this project?

Should I really change the beahaviour of the JsonTextReader and try to fix Skip(), or should this problem be handled higher up in the chain, like in JsonSerializerInternalReader?

/b

Currently it's hard to flow a single custom name table through the system. It's possible to override on the default contract resolver via reflection but this is quite messy, especially when doing something like AddNewtonsoftJson in ASP.NET Core.

Would it be possible to expose the PropertyNameTable directly on JsonSerializerSettings or similar so that it flows through all uses?