Newtonsoft.json: .NET Standard 2.0

Created on 5 Sep 2017  路  20Comments  路  Source: JamesNK/Newtonsoft.Json

Is a .NET Standard 2.0 version planned?

netstandard20

Most helpful comment

the way i'd put it is that it isn't _strictly_ needed, and wouldn't be useful at all if .NET was bug-free. but we do not live in an ideal world, so it can sometimes be useful.

All 20 comments

Hi,

what would be the benefit of a .NET Standard 2.0 version?
Looks like the library needs "just" .NET Standard 1.0.

@hachimagu Doesn't nuget target core 1 explicitly though, which results in pulling down all of the libs for core 1 into your core 2 project and can cause clashes between the two?

I got this exact issue when running a .NET Standard 2.0-project. There is no way to pull down Newtonsoft.Json without getting .NET Standard 1.3-dependencies. Thus effectively rendering the application unusable.

https://stackoverflow.com/questions/46155517/i-get-exception-could-not-load-file-or-assembly-when-running-as-console-using

Is the issue related to this: https://github.com/dotnet/standard/issues/481?

I believe the fix has to happen on Microsoft's side. Everyone releasing new versions of every library each time there is a new .NET Standard won't work.

Sorry this wasn't the same issue @JamesNK please consider reading my answer in Stack Overflow as it clarifies the issue. Now, the solution isn't a good one, but at least I got it working. Thanks for the enthusiasm and your contribution to the community!

The only benefit of a ns2.0 build is reduced dependencies for projects that trim out these dependencies during build anyway (nca2.0+, net461+) and zero dependencies and added dlls added for the upcoming net471.
But sice the package already contains .NET Framework DLLs, they are preferred for .NET Framework projects anyway so the only benefit would be to would be reduced dependencies for .NET Core 2.0 apps (tbh maybe not worth it)

it's definitely possible to make the existing version work (either by developers getting all the pieces right or microsoft updating their side). an ns2.0 version would improve build times, though- right now the 1.x-era deps are the vast majority of a tree

Build times is a great plus.. sadly there's also a few bugs in netstandard < 2.0 support for netcoreapp2.0/net461+ which are nice to avoid with ns2.0 native package assets (https://github.com/dotnet/cli/issues/7563#issuecomment-328878574, https://github.com/dotnet/sdk/issues/1510) but aren't package author concerns (though newtonsoft.json will likely be blamed as it is the example package)

tbh maybe not worth it

@dasMulli, over the past few weekends, I sent couple of pull requests to different libraries, adding explicit NET Standard 2.0 TFM support. My understanding was for library authors, explicitly targeting frameworks, where dependency graph differs or code path improves (like it enabled XML serialization in fluentassertions on .NET Core), is a right thing to do. Secondly, I thought restoration complies very well with it as extra dependencies do not get pulled. For instance, dependencies section of Newtonsoft.Json on Nuget:


Expand to view screenshot

image



will have one more entry for .NETStandard 2.0 and underneath it will state No dependencies. This will help the downstream scenarios, where consumer is doing: dotnet restore -f netcoreapp2.0 and hence will not pull dependencies such as NETSTandardLibrary 1.6.1.

Or did I miss the point? Is it really not needed (restore utility will do the right thing)? 馃槷

the way i'd put it is that it isn't _strictly_ needed, and wouldn't be useful at all if .NET was bug-free. but we do not live in an ideal world, so it can sometimes be useful.

I agree with @gulbanana on this one. Ideally it wouldn't be needed, but we don't have an ideal situation. :)

Supporting .NET Standard 2.0 enable using some converters like DataTableConverter and DataSetSonverter.
see that issue serializes a DataSet to JSON on dotnet core 2.0 #1409

To be ready for .NETStandard 2.0, Json.net have to wait the update of its nuget dependency packages:
System.Runtime.Serialization.Primitives (current support .NETStandard 1.3)
System.Runtime.Serialization.Formatters (.NETStandard 1.4)
System.ComponentModel.TypeConverter ( current support .NETStandard 1.5)
System.Xml.XmlDocument (.NETStandard 1.3)
Microsoft.CSharp, It's already updated to .NETStandard 2.0
I hope the nuget packages will be ready sooner :)

Update:
I did POC for the readiness of json.net in .netstandard2 (based on netstandard1.3 version and enabling DataTableConverter and DataSetSonverter and find errors(39) :

Error: 'BindingFlags' is an ambiguous reference between 'Newtonsoft.Json.Utilities.BindingFlags' and 'System.Reflection.BindingFlags' (DefaultContractResolver.cs)

Warning: The type 'FormatterAssemblyStyle' in 'FormatterAssemblyStyle.cs' conflicts with the imported type 'FormatterAssemblyStyle' in 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

I expect that json.net can be ready quickly without waiting to the update of dependency packages(but sure need more investigation and pass all unit test).

there are no dependencies needing updates; in ns2.0, all of those libraries are subsumed by netstandard.library. the question is whether or not to increase the complexity of the build in order to add a TFM which shouldn鈥檛 be technically necessary but works around bugs in the consuming sdk

@gulbanana, I agree , and I removed all the dependency package from POC.
I expect the complexity will be minimum.
In .NET 4.7.1, .netstandard assemblies will be put in the framework in that version (as said by @weshaggard) so you will no longer need to carry them with your application and it will be much like .NET Core at that point.
Answer to my question in netstandard project

Thanks! It must be a hassle to maintain even more variants, but you've really helped out my build times.

Pardon my ignorant question, but when will this change be reflected in a release package on nuget.org? I assume those already using it are building the project themselves?

Same question as @k3davis.
In the meantime, what I did is downloaded the source, compiled from it and built a package.
Then I followed the steps here to host it in a private nuget feed.
But it comes short when I need other components that already depend on it like Refit for instance...

I did the same James here. Worked perfectly :D Thaaankksss

https://github.com/JamesNK/Newtonsoft.Json/issues/1759

Was this page helpful?
0 / 5 - 0 ratings