Use the "highest" dependency version setting when resolving dependencies with nuget

[AnthonyMastrean]

I often have sets of packages like foo, foo.install, and foo.portable, where the default package simply depends on the install package. I usually set a thoughtful, but loose version range so I wouldn't have to constantly update the default package.

For example, depend on any version in the 1.x major range.

<dependency id="foo.install" version="[1.0, 2.0)" />

However, the default resolution was to pick the lowest major & minor versions that satisfy those criteria. So, even if I published an install package at 1.1, 1.2, and so on, you would never get those from installing the default package.

So, I end up being more restrictive with the version range specification and updating the default package more often anyway :(

NuGet 2.8 introduces finer grained control over dependency resolution. It seems to make sense for me, the wider audience of package maintainers, and the intentions of Chocolatey to select the highest dependency version that satisfies.

nuget.exe ... -DependencyVersion Highest

What do you think?

[ferventcoder]

I think this is perfect. This is what NuGet should have done and one thing that made me want to start looking else where. Is .NET 4.0 still supported in NuGet 2.8?

[nabheet]

Does chocolatey support any kind of version range specification like "[1.1, 2.0)"?

[ferventcoder]

@nabheet yes in the nuspec.

[ferventcoder]

@AnthonyMastrean NuGet indeed did introduce Dependency Resolution strategy, but they didn't expose it as all in NuGet.exe. Sad but no matter as choco.exe does it just fine. https://github.com/chocolatey/choco