Standard: Newtonsoft.Json in .NET Standard: good idea or no?

[JamesNK]

Newtonsoft.Json is the most downloaded and referenced NuGet library. It is also pretty stable. There isn't major development going on at the moment, changes are mostly bug fixes.

Putting the idea out there to weigh up the pros and the cons: should Newtonsoft.Json be in .NET Standard?

[vincentparrett]

I think this is a great idea, it's pretty much the first nuget package I install in any project, and by any project I mean every project... it's pretty much the first thing I do. It is the standard now... make it formal!

[Richard004]

16/7:
Yes. It should be. It is a building block for almost anything.

If string is in Standard and Object is in Standard, then "Jameson" should be there as well.

17/7 Edited: Reading all the comments bellow make a lot of sense.
I am comfortable to agree with you all guys. Json.Net is great as it is anyway.

[terrajobst]

I don't think it's a good idea. My rationale is part of the FAQ.

[timdoke]

Just playing devil’s advocate here.. but if it were part of standard then you wouldn’t be able to update it as freely. And you would lose ownership. Not necessarily a bad thing as it is a pretty standard toolkit/library. But, considering that msft uses it in their project templates means it prolly should be part of standard.

Personally, I don’t use this library much. I leave it installed of course.. I prefer faster serializers like utf8json: https://github.com/neuecc/Utf8Json. Now, if you could offer the performance of that, I’d like it a lot more..

[terrajobst]

@timdoke says it better than I did.

Also, it's worth pointing out that the ability to update JSON.NET aren't just limited to API surface. All APIs that are part of .NET Standard must be shipped by each .NET platform. And those don't let you update the implementations out-of-band. Bug fixes would now have to be merged and distributed by all .NET platforms. I'm not sure that's a good trade-off...

[benaadams]

Newtonsoft.Json can happily be used on any platform currently.

Changes to .NET Standard should be the minimal set that can't be supported easily via NuGet (i.e. changes to existing types currently in the Standard and new types directly used by those types)

If its a package that and happily lives in NuGet and sits on top of the Standard then all runtimes get it for free.

If its put in the Standard then it comes with a cost for every runtime (even if its a copy+paste cost) as they must implement it to abide by the Standard and to expose the apis.

[clairernovotny]

I don't think the .NET Standard is appropriate for Json.NET, but I do think that the .NET Foundation is. The Foundation can work with the projects to help ensure continuity and succession, for "hit by a bus" or other scenarios.

[bradwilson]

A fast/lightweight JSON parser belongs in the standard.

JSON.NET should stay where it is.

[urbanit]

Keeping it as package makes more sense to me.

[ghuntley]

Changes to .NET Standard should be the minimal set that can't be supported easily via NuGet (i.e. changes to existing types currently in the Standard and new types directly used by those types)

In agreement with Ben here. Netstandard is wall putty. It's used to smosh out what's missing in all of the different implementations of dotnet. It's not glue to add new features. There's a tool for that and it's name is nuget.

[ghuntley]

The real conversation here should be one of succession. James you have built something that everyone in dotnet uses. It's unfair that the burden of maintenance and support for a programming language falls onto a single unpaid maintainer. Maybe it's time to take @onovotny up on that offer and start the search. Creators shouldn't be shackled to their creations for life.

[vivainio]

The API is way too big for the standard (especially with all the contract resolving etc).

With a system like Python's "json" module, it would be a no-brainer (it just converts json to dicts), but JSON.net has tons of ways to configure how POCO's map to json.

[alexdegroot]

I'd very much like the idea of a standard, light weight, fast, implementation free set of interfaces in the standard. I'm thinking then of a set of interfaces which do exactly what we like about serializers in the recommended way. Think about the loading async, from filestreams and potentially using IO.Pipelines and Span/Memory, etc.
My aim would be to deliver the best practices for usage, abstraction and performance without dealing with an implementation. In this way, initiatives such as Newtonsoft.Json.Net, Utf8Json and JsonSpan could implement this interface and those serializers could be injected into processing classes as we know them from ASP.NET Core.

[rvhuang]

I would prefer having something like DataMemberAttribute to standardize serialization behaviors and let third parties to follow and implement.

[arthurrump]

I don't think Newtonsoft.Json should be inside .NET Standard. It currently works across all frameworks that implement the standard, so I don't really see the benefit of putting inside the standard. As @benaadams already mentioned, it would also mean that every runtime would have to do the same work again. Not to mention the potential problem of having to deal with slightly different implementations across Core, Framework and Mono, because a bug was fixed in one, but not yet in another, or because you're stuck with a certain version of that runtime in your environment. In the current model you are not dependent on runtime updates to get your bugfixes: you update the NuGet and it will just work in every runtime. In short, I think it will create more problems than it would solve.

[vectorix]

Should Newtonsoft Json become a .NET Standard? No. Part of .NET Foundation? Sounds good.

Should .NET have built-in JSON support, like XML? Probably. But then it should be an effort started from scratch, with API reviews, and must be as high performing and light weight as possible and integrate with all high performance primitives in the ASP.NET Core pipeline, use intrinsics where appropriate, etc. The namespace should be starting with "System" something. Probably it can start in corefxlab or similar place. It can then move into .NET core and mature there.

[peval27]

It seems a pretty bad idea. It's a stable and well known Nuget package, which can be used by any .NET platform. Including in .NET standard will force each platform to implement and maintain it. Don't really see the value here.

And for those who think .NET framework should implement a lightweight JSON parser... why? The only use case would be to have an extension method .ToJSON() and a JSON attribute. But again, it seems preferrable to pull in JSON.NET.

[talanc]

I think .NET Standard should be part of Newtonsoft.Json. It's stable and used practically everywhere in .NET projects, it's pretty much what .NET Standard wants to be.

If anything they should merge with your project, and then rebrand themselves to NSFT on the stock market.

[clairernovotny]

@peval27 not all libraries can use json.net because of dependency issues. For example, xUnit cannot, since James uses it to test it.

We have a custom internal implementation because of that. It'd be better if there was a built-in one we could use that was lightweight and fast.

[peval27]

@onovotny I wasn't aware as I use MSTest and NUnit... thanks for pointing out!

[AndrewMutation]

The only issue I see with having a different lightweight json parser built-in is that we may need to the ability to seamlessly replace it with Newtonsoft.Json.

[ZigMeowNyan]

I agree with @rvhuang in that I think having solid, format-agnostic attributes as part of the core API is a more important concern. If we could get a set of attributes that could describe object structure in multiple formats without introducing dependencies on specific formats, it would help portability.

Some examples: it'd be nice to have one set of attributes that could map an object collection to an array property in languages like JSON, but could also provide details on both the collection name and item names in languages like XML that can have multiple ways of handling collections. There's also things like null-handling, ignore attributes, allowing the attributes on interfaces, interface collections (e.g. List<IBusinessObject>), reflection and dependency injection hints, format-specific tags for attributes, etc, that are all worth a review to see if we have a good solution for library authors to work with. In the end, maybe we could reduce the need for libraries like Newtonsoft.Json to implement their own attributes for this sort of thing and fragment behavior.

[JamesNK]

General consensus is Newtonsoft.Json as a package works ok today and it would be too heavy for .NET Standard, which I agree with. Thanks everyone!