My team now has 5 packages on NuGet (yesterday we dropped another one, a preview to immutable collections) and by far our number one support question has been due to an older version of NuGet being installed. We take heavy advantage of the new portable
and Windows Phone 8 lib folders (introduced in 2.1) – and attempting to install our packages to projects targeting those results in a very unhelpful error message:
Could not install package 'Microsoft.Bcl 1.0.0-alpha'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile4', but the package does not contain any assembly references or content files that are compatible
with that framework. For more information, contact the package author.
There are also cases where we want to take advantage of bug fixes (such as this:
) in later versions of NuGet that would result in unexpected behavior if those versions were not installed.
We’d like the ability for a package to require a specific version of NuGet to be installed so that we can reduce customer confusion and reduce our support cost.
Edited by dotnetjunky, copied from #2936
Presently, the client cannot detect what version of NuGet is needed until the package is downloaded and unzipped. We should store metadata on the server to indicate the client version required and display it and block installation if the client is not compatible.
The client would fall back to current behavior if the server doesn't provide the NuGet version required for the package.