-
-
Save JamesNK/56b1c3b90b2a8d21c73d to your computer and use it in GitHub Desktop.
<?xml version="1.0" encoding="utf-8"?> | |
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd"> | |
<metadata> | |
<id>Newtonsoft.Json</id> | |
<version></version> | |
<title>Json.NET</title> | |
<description>Json.NET is a popular high-performance JSON framework for .NET</description> | |
<authors>James Newton-King</authors> | |
<language>en-US</language> | |
<projectUrl>http://www.newtonsoft.com/json</projectUrl> | |
<iconUrl>http://www.newtonsoft.com/content/images/nugeticon.png</iconUrl> | |
<licenseUrl>https://raw.github.com/JamesNK/Newtonsoft.Json/master/LICENSE.md</licenseUrl> | |
<tags>json</tags> | |
<dependencies> | |
<group targetFramework="net45" /> | |
<group targetFramework="wp8" /> | |
<group targetFramework="win8" /> | |
<group targetFramework="wpa81" /> | |
<group targetFramework="xamarin.ios" /> | |
<group targetFramework="monotouch" /> | |
<group targetFramework="monoandroid" /> | |
<group targetFramework=".NETPlatform5.0"> | |
<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" /> | |
</group> | |
</dependencies> | |
</metadata> | |
</package> |
BTW, I agree that the strategy is different for a dotnet
library which is really a PCL259 vs. one which is actually built for dotnet
. Obviously, every PCL259 is compatible with dnx451
, but you have to work hard to ensure that a built-for-dotnet
library is actually down-level compatible with dnx451
.
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.
This moniker is not directly tied to any specific version or framework capabilities, but rather is an indirect reference that tells NuGet: “this is the reference you should use if it supports the framework and runtime capabilities that you have”. The NuGet client will then investigate that reference to determine what features and frameworks it supports. This process continues until the NuGet client resolves the exact features supported by the dotnet reference and will then apply it if and only if it matches the features and requirements of your project. The dotnet moniker can be referenced by .NET Framework 4.5 and later derived framework versions including Xamarin Android and Xamarin iOS.
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 portable-*
if dotnet isn't compatible (though an argument could be made that it should!)
To the very best of my knowledge, my understanding is specific TFM
> dotnet
> portable-*
. So if you have dnx451
as a TFM in either the lib or the dependencies, that'll be used instead of dotnet for dnx451
->dnx46
since that'd be "more sepcific." dotnet though would be used over portable-*
for NuGet v3, (so not VS 2013).
So as above, with the current library layout from the beginning of this thread, win8 would get the dotnet target and fail because System.Runtime 4.0.20
isn't compatible. You'd need a \lib\win8
for it to use (and ditto for all of the there frameworks that can't use the .net core package versions (pre 4.6).
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 system.runtime 4.0.20
) that don't support older pre-4.6 runtimes. Like a System.Runtime 4.0.10
dependency would not support .net 4.5 but would support .net 4.5.1.
@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.
It doesn't evaluate
dotnet
and then fallback toportable-*
ifdotnet
isn't compatible (though an argument could be made that it should!)
+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 System.Runtime
will be assumed to be compatible with dotnet
. This includes all the way back to net45
, win8
, wp8
, and wpa81
(plus the net45
-alikes, like Xamarin).
The only way to tell NuGet that your dotnet
library is not compatible with these things, but an alternative exists, is to list it explicitly. This means you need at a bare minimum a platform-specific library; also, if the dependencies listed for dotnet
are not appropriate, you also need a platform-specific dependency group.
IMO, this is all made worse by the Visual Studio tooling pretty much making you assume that dotnet
== net46+uwp10.0+dnxcore50
. You can make your dotnet
library actually compatible with the all the down-level platforms (we did it with xUnit.net's execution library) by throwing away the tooling default project.json and being explicit about your dependencies.
@bradwilson I generally agree with your assesment, we are looking at ways to
a. Clearly document what needs to be done
b. Improve the system so its not so sucky.
So bare with us for a few more days until we can figure out how to make it better
@JamesNK and about testing - we should provide an easier way to test at least the restore using nuget.exe. It will be kinda hard to verify 100% because with project.json
you depend on msbuild to do the right thing as well.
So this isn't true then...
This moniker is not directly tied to any specific version or framework capabilities, but rather is an indirect reference that tells NuGet: “this is the reference you should use if it supports the framework and runtime capabilities that you have”. The NuGet client will then investigate that reference to determine what features and frameworks it supports. This process continues until the NuGet client resolves the exact features supported by the dotnet reference and will then apply it if and only if it matches the features and requirements of your project. The dotnet moniker can be referenced by .NET Framework 4.5 and later derived framework versions including Xamarin Android and Xamarin iOS.
http://blog.nuget.org/20150729/Introducing-nuget-uwp.html
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.
Going to fix the blog
That hasn't been my experience. Don't forget that there's a different selection logic for "what I link against" vs. "whose dependencies I absorb".