DescriptionJson.NET is a popular high-performance JSON framework for .NET
Topics c-sharp
Open issues606
Last push12/4/2021 8:00:46 PM +00:00
Github URLhttps://github.com/JamesNK/Newtonsoft.Json
Clone URLhttps://github.com/JamesNK/Newtonsoft.Json.git
SSH URL[email protected]:JamesNK/Newtonsoft.Json.git

Most active issues

Topic# Comments
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("{ 'x': '2016-03-31T07:02:00+07:00' }");

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

The problem disappears if we specify how to parse dates:

var obj = JsonConvert.DeserializeObject("{ '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?

Read comments
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.

Read comments
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:


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.Dictionary<TKey, TValue>
System.Collections.Generic.SortedDictionary<TKey, TValue>

© Microsoft Corporation. All rights reserved.

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

Read comments
Getter-only properties in C# are [`readonly`](https://msdn.microsoft.com/en-us/magazine/dn802602.aspx), 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("{\"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.

Read comments

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

Read comments
With C#7 coming out within a week, I was looking into the new features and the new Tuple feature with named elements seems like something Json.NET should support if possible.

As a root object I don't think this would be possible as Tuple element names are erased upon compilation and are only present at API boundaries, i.e. type fields and properties and method parameters and return parameters, through the `TupleElementNamesAttribute`. But when exposed as a Field or Property the element names could be retrieved through reflection with this attribute and be used instead of `Item1`, `Item2`, etc...

Read comments
Contributes to #650

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

Read comments
Because of [a question on SO](http://stackoverflow.com/q/14483218/41071), I went to investigate how does async work in JSON.NET. When I looked at the code (specifically [JsonConvert.cs](https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json/JsonConvert.cs)), I noticed that the async methods (like [`SerializeObjectAsync()`](https://github.com/JamesNK/Newtonsoft.Json/blob/787bde6e15e6adfb4e606f77fa9d0bd4c7377cc6/Src/Newtonsoft.Json/JsonConvert.cs#L1018)) just call the synchronous version using `Task.Factory.StartNew()`.

This is generally not a good idea, because `Async` methods are usually more scalable than their synchronous version, but this isn't true for your implementation. For more information (and a better explanation), see Stephen Toub's article [_Should I expose asynchronous wrappers for synchronous methods?_](http://blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx)

Because of that, I think you should remove the Async versions of your methods from the library.

Where adding `Async` versions would make sense is when working with streams, but doing so would require a lot of changes in classes like `JsonTextReader` (and I'm not sure how to do it without duplicating a lot of code in a way that doesn't break JSON.NET for older versions of .Net).

Read comments
I am not really sure if this is a bug or the functionality has changed in the latest versions but after updating a web api project from Newtonsoft.Json version 4.5.11 to version 6.0.6 I discovered that the annotations were actually ignored and the serialization occured even for the properties that were annotated as JsonIgnore.

In order to annotate the objects I use buddy classes:

public partial class Customer

public class CustomerValidation
public System.Guid UpdatedBy_Id { get; set; }

If this is not a bug, how can the same functionality be accomplished in the latest version?

Read comments
Avoids string allocation

Read comments