Today we have the -dependencyVersion option on PMC install and update as well as the dependencyVersion option in the config. It only applies to packages.config.

We could introduce support to project.json world by lifting transitive dependencies to the parent project.

Example

Consider you have a project.json and you want to install WindowsAzure.Storage 6.2.0. This package depends on Newtonsoft.Json 6.0.8. Today if you install WindowsAzure.Storage, you will get a project.json like this:

{
  "dependencies": {
    "WindowsAzure.Storage": "6.2.0"
  }
}

In the lock file, NuGet would have resolved the lowest version that meets the dependency's spec, which means that Newtonsoft.Json 6.0.8 would be restored.

With DependencyBehavior.Highest, the highest version of Newtonsoft.Json should be picked (which is 9.0.1 today). Since project.json default behavior is taking the lowest, we could observe this DependencyBehavior.Highest option by lifting Newtonsoft.Json 9.0.1 to the project.json automatically, resulting in a project.json that looks like this:

{
  "dependencies": {
    "WindowsAzure.Storage": "6.2.0",
    "Newtonsoft.Json": "9.0.1"
  }
}

-dependencyVersion in restore?

Lifting dependencies to the parent is one possibility, but this causes the user's project to become crowded with a potentially huge number of transitive dependencies (just look at the full graph of NETStandard.Library metapackage).

Another approach would be to support -dependencyVersion in restore itself so that, as NuGet walks transitive dependencies, it picks Highest instead of Lowest as it goes. This is a significant behavior change in project.json and, as @emgarten notes, this can lead to wacky results especially with CoreFX packages that change a lot from one minor release to the next.

More thought and design needed.