Project.json restore should warn when top level packages violate constraints

[emgarten]

The below project.json should generate a warning for the constraint violation between Microsoft.ApplicationInsights >= 2.0.0 and == 1.2.3 required by the WindowsApp package.

Ideally there should also be a way to suppress these warnings.

{
  "dependencies": {
    "Microsoft.ApplicationInsights": "2.0.0",
    "Microsoft.ApplicationInsights.PersistenceChannel": "1.2.3",
    "Microsoft.ApplicationInsights.WindowsApps": "1.1.1",
    "Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0",
    "Win2D.uwp": "1.16.0"
  },
  "frameworks": {
    "uap10.0": {}
  },
  "runtimes": {
    "win10-arm": {},
    "win10-arm-aot": {},
    "win10-x86": {},
    "win10-x86-aot": {},
    "win10-x64": {},
    "win10-x64-aot": {}
  }
}

[lindydonna]

@emgarten Shouldn't it be more than a warning? In previous versions of NuGet, it would be an error.

[emgarten]

@lindydonna you can find more information on how dependencies are resolved here:
https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution

PackageReference projects allow overriding dependencies constraints to allow the user to have full control over dependencies and make the ultimate decision as to which package/assemblies are used in their build.

Packages may have strict dependencies that only allow a single version of a package, and if the constraints are not met as the doc above describes the install/update/restore will fail with a helpful message. Users can then decide which package they want to use and install it top level, which will override the conflict.

With packages.config the error was blocking and a common problem for users as package dependencies grew. For example if a project depends on two unrelated sets of packages, and each set requires different exact versions of the same package the user was blocked and required the package author to change the packages to resolve the issue.

Often times these package constraints were based on older versions of the dependency, if a version of the dependency in the future solved all issues, or if the user knew that it was safe to user another version because the were not actually calling APIs that the package was trying to block then it was still blocked for the user.

Removing this feature for PackageReference and failing would be a breaking change, and I expect it would impact a large number of users relying on this currently.

Issues with overriding commonly occur due to users not realizing that they have the ability to force a specific version of a package, typically through the NuGet install UI or update UI where it is less obvious that this could happen. I think that can be improved, along with restore output to make it more clear what is happening.