|<?xml version="1.0" encoding="utf-8"?>|
|<description>Json.NET is a popular high-performance JSON framework for .NET</description>|
|<group targetFramework="net45" />|
|<group targetFramework="wp8" />|
|<group targetFramework="win8" />|
|<group targetFramework="wpa81" />|
|<group targetFramework="xamarin.ios" />|
|<group targetFramework="monotouch" />|
|<group targetFramework="monoandroid" />|
|<dependency id="Microsoft.CSharp" version="4.0.0" />|
|<dependency id="System.Collections" version="4.0.10" />|
|<dependency id="System.Collections.Concurrent" version="4.0.10" />|
|<dependency id="System.ComponentModel.TypeConverter" version="4.0.0" />|
|<dependency id="System.Diagnostics.Debug" version="4.0.10" />|
|<dependency id="System.Diagnostics.Tools" version="4.0.0" />|
|<dependency id="System.Dynamic.Runtime" version="4.0.10" />|
|<dependency id="System.Globalization" version="4.0.10" />|
|<dependency id="System.IO" version="4.0.10" />|
|<dependency id="System.Linq" version="4.0.0" />|
|<dependency id="System.Linq.Expressions" version="4.0.10" />|
|<dependency id="System.ObjectModel" version="4.0.10" />|
|<dependency id="System.Reflection" version="4.0.10" />|
|<dependency id="System.Reflection.Extensions" version="4.0.0" />|
|<dependency id="System.Runtime" version="4.0.20" />|
|<dependency id="System.Runtime.Extensions" version="4.0.10" />|
|<dependency id="System.Runtime.Numerics" version="4.0.0" />|
|<dependency id="System.Runtime.Serialization.Primitives" version="4.0.10" />|
|<dependency id="System.Text.Encoding" version="4.0.10" />|
|<dependency id="System.Text.Encoding.Extensions" version="4.0.10" />|
|<dependency id="System.Text.RegularExpressions" version="4.0.10" />|
|<dependency id="System.Threading" version="4.0.10" />|
|<dependency id="System.Threading.Tasks" version="4.0.10" />|
|<dependency id="System.Xml.ReaderWriter" version="4.0.10" />|
|<dependency id="System.Xml.XDocument" version="4.0.10" />|
Welcome to The Great Newtonsoft.Json.nuspec Collaboration!
tl;dr; a nuspec needs lots of dependencies now are and there are no samples on how to actually do it
The Json.NET NuGet package has:
dotnet should be used by DNX. I'm guessing Win10 UAP projects should use it as well, although I'm not familiar with them. Will win8 clash anywhere? I don't know. Do you?!?!?!!111one
What needs to change to get everyone playing along? Comment and I'll edit the nuspec
One thing to keep in mind: specific TFM > dotnet > portable-*
System.Runtime 4.0.0 = .NET 4.5 equivalency (plus win8, wp8, mono*)
This means that depending on what's in your dotnet sections, you may need blank groups to prevent other system.runtime based platforms from using that package if they're older than your minimum versions. Starting with .NET 4.6, these versions should not matter as the newer BCL packages should work there too.
Here's what I make of it so far given your dependency and \lib structure:
I take it back, there's one thing that's probably broken:
The issue is that your
@bradwilson Will that issue go away if I reference System.Runtime 4.0.0 instead of 4.0.20? (and 4.0.0 for everything else). Since Json.NET really just uses things from .NET 4.5 I'm guessing I don't need anything higher than 4.0.0. I just referenced the latest versions of everything because I could.
@onovotny Would using uap for the targetFramework be preferable over uap10.0? Keeping the version number out of it should hopefully keep future versions of uap happy.
I didn't know that the version numbers matched up in that way. Useful info!
@JamesNK Yes, but to do that the right way, you need to stop using the meta-packages in project.json and use the individual packages with the specific versions you need. You need to use NuGet to look at every reference you're taking, to make sure you're choosing a .NET 4.5-compatible version (like System.Runtime 4.0.0).
Note that the compiler will complain at you about the conflicting references (f.e., System.Linq 4.0.0 "requires" System.Runtime 4.0.20 when you're linking against
Don't be surprised if you find things missing. xUnit.net had to forego access to a lot of System.IO, and ExecutionContext, to link against the .NET 4.5 contract assemblies. It might make more sense in that scenario to duplicate the
@bradwilson I built a NuGet package with the nuspec above and tested it in a DNX app:
It ran without issue. Am I not seeing any problems because I have .NET 4.6 on my computer?
How can I see what .NET version a package requires?
Shouldn't an empty dnx451 group be enough? dnx451 would then fall back to net45 instead of dotnet.
Just thought of one thing given the above structure...
If you're in VS 2015 with NuGet v3, then the version in \lib\dotnet will be used by Win8, wp8, wpa81 and the Xamarin ones because dotnet > portable-*.
That may or may not be an issue depending on what's actually in dotnet (is it the Profile 259 PCL or a newer project.json modern lib)?
BTW, I agree that the strategy is different for a
Are you guys sure dotnet will always be used ahead of portable-* and dnx451? (I would test it myself but I don't have VS2015 on my current machine)
The impression I get from here - http://blog.nuget.org/20150729/Introducing-nuget-uwp.html - is the dotnet target's dependencies will be analyzed and the client will determine whether dotnet is compatible with the project's framework capabilities.
So for a win8 project referencing Json.NET the NuGet client will look at Json.NET's dotnet target, see that it depends on System.Runtime 4.0.20, know that 4.0.20 isn't supported in win8 and fall back to portable-net45+wp80+win8+wpa81 (aka PCL259).
So I thought that dotnet should work like that but that's not how it appears to work. It dosn't evaluate dotnet and then fallback to
To the very best of my knowledge, my understanding is specific
So as above, with the current library layout from the beginning of this thread, win8 would get the dotnet target and fail because
As @bradwilson said, you can get away with a lot more with a Profile259 PCL in the dotnet folder because that would use the 4.0.0 contract package references, which are supported by all of the frameworks. Where it gets hairy is if what you put in dotnet requires dependencies (like
@JamesNK its going to take me some time to process a reasonable and coherent answer. I get the frustration this is causing, and I want to take the time to alleviate this pain properly. So excuse me for not jumping into this long thread with a magic bullet, I'll work on it tomorrow.
+1. Despite what we had all hoped, it does not do this (and at this point, we shouldn't expect that it ever will, because that would fundamentally change the design of the system). This is the key takeaway:
By default, anything which is eligible to use
So this isn't true then...
As far as I can tell dotnet is useless. It hides portable-* for win8/wp8/wpa81/net45 so the assembly in dotnet has to be compatible with all those targets.