Mysterious Newtonsoft.Json conflict when depending on a library from a Web app

[jeffschwMSFT]

Port of https://github.com/dotnet/cli/issues/2605

The root issue is that this is an undiscoverable problem that developers will struggle to fix. The simplest fix would be to doc it, but I encourage us to look for diagnostics that help lead developers to a working solution.

[cevarief]

[MacOSX] Same, if i add EF package it throw errors

"tools": {
    "dotnet-ef": "1.0.0-rc2-*",
  },

Output :

Errors in ~/Development/aspnet/blog/project.json
    Package Newtonsoft.Json 8.0.3 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Newtonsoft.Json 8.0.3 supports:
      - net20 (.NETFramework,Version=v2.0)
      - net35 (.NETFramework,Version=v3.5)
      - net40 (.NETFramework,Version=v4.0)
      - net45 (.NETFramework,Version=v4.5)
      - portable-dnxcore50+net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=net45+wp80+win8+wpa81+dnxcore50)
      - portable-net40+sl5+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile328)
    One or more packages are incompatible with .NETCoreApp,Version=v1.0.

[yishaigalatzer]

@cevarief this is not the same issue. You need to add imports, and this is being fixed by updating newtonsoft.json to actually support netcoreapp

@jeffschwMSFT the behavior is by design, you have an import statement in one project that is a backdoor to allow packages that are not guaranteed to be compatible to be added to your project. So imaging this project is packaged (projects and packages are interchangeable). Installing a package that is not compatible will indeed throw that error, and hence adding project A to project B breaks it.

Let me share an example from the world before NuGet:

1. Project A works, and targets .NET 4.5
2. Project B works and targets .NET 4.6

Project A Cannot depend on project B. This is in essence exactly the same thing (just transitively bringing in newtonsoft.json)

So I agree that we could be more helpful with the error message, but sending people to add imports blindly will cause more problems then help (see @cevarief 's scenario). We need to figure out a story of how to surface an error. In the project 2 project scenario we might be able to detect that imports in the dependant project and let you know, when it is the package case we could send to a link on the web with an article describing this in more details

CC @harikm86

[JamesNK]

FYI a .NET CLI/netstandard version of Json.NET is ready, but I can't really put it on NuGet until RC2 is on NuGet.

JamesNK/Newtonsoft.Json@master...dotnet-cli

[harikmenon]

Adding this to doc tasks on our end

[natemcmaster]

@harikm86 can we put something about imports in the error message? This seems like a OOB error lots of people will have.

[yishaigalatzer]

This will go away when James publishes. We don't want to encourage the import it's a hack

[natemcmaster]

This will go away when James publishes

For Newtonsoft.Json, but what about other packages?

Entity Framework will still need imports because it depends on external packages: Ix-Async and re-linq. Although we have started collaboration with them to support netstandard, it may take a while. cref dotnet/efcore#5176

[yishaigalatzer]

Exactly the same answer. This will drive other package owners to fix them. We do not want to promote imports as a solution, because it isn't really a solution it is a rough approximation.

[natemcmaster]

IMO I don't see the harm in adding a fwlink to docs. The docs could still explain why imports are not the best but necessary. The primary issue I'm picking at is that path from the error to the fix is Google search results, scanning release notes, and finally some project.json wizardry. Not a great OOB, day-one experience. A link in the in error can guide users to a solution.

[kraigb]

The Package Restore page now has a section on dealing with the compatibility error messages. https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution#resolving-incompatible-package-errors