NuGet.exe restore has a misleading message about the MSBuild versions supported.

[eriawan]

Details about Problem

NuGet product used: NuGet.exe :

NuGet version (x.x.x.xxx): tested on 5.3.1.6268 and 5.2.0.6090

VS version (if appropriate): VS 2019 16.4.1 and VS 2019 16.3.5

OS version: Win10 v1909 build 18363.535

Worked before? N/A

NOTE:
nuget restore -h shows this:

Detailed repro steps so we can see the same problem

1. Ensure VS 2019 (16.3.x or later) is installed, and ensure nuget.exe (with versions above) is download.
2. Open Developer Command Prompt for Visual Studio 2019.
3. Run nuget restore against any solution file on the command prompt with -MSBuildVersion 16.0, because this is one of the allowed values as indicated by captured values for MSBuildVersion above.
4. The error shows that it doesn't recognize the version

...

Suggestions

The value of 16.0 should refer to the version of the VS 2019 MSBUILD , or please update the option of -MSBuildVersion to use the exact version of VS 2019, such as 16.4 for VS 2019 16.4.x. Otherwise it is confusing in the beginning.

Verbose Logs

Cannot have verbose logs, because nuget.exe failed to run immediately:

Sample Project

Sample projects aren't quite necessary, because any .NET (including net FX and NET Core) projects will always be reproducible.

[dominoFire]

Thanks for pointing out this problem, @eriawan

-MSBuildVersion is used to specify the exact version of MSBuild you want to use for the restore operation, just like you commented in your suggestion: 16.4 for VS 2019 16.4.x, 16.3 for VS 2019 16.3.x, VS 2017 15.9 for 15.9.x and so on.

Also, we're open to accept a PR for making this message better.

[eriawan]

@dominoFire
I'd love to submit a PR on this.
CMIIW, if we're just updating the error message, then the error message is not fully solving the problem. I think NuGet CLI (nuget.exe) should be displaying the error message and also tell us the closest version to the supplied parameter.

For example, if I run this on machine that has VS 2019 16.4.x installed with VS 2019 Developer Command Prompt:

nuget restore AnySolution.sln -MSBuildVersion 16.0

I should get this error:

Cannot find the specified version of msbuild '16.0'. 
The highest installed msbuild detected is '16.4', use this version explicitly or restore without MSBuildVersion as nuget will detect and use the highest installed of msbuild.

What do you think?

[nkolev92]

@eriawan

NuGet will try to work with pretty much any msbuild version, the challenges is the capabilities that'll be enabled.

In practice, it's best to match NuGet to match the MSBuild version that ships around the same time.

Given a Visual Studio/MSBuild version of x.y.z equation is something like Visual Studio Major - 11.y.z.

So 5.4 of NuGet is best used with 16.4 of MSBuild.

Per this, I'm retitling and repurposing this for improving the message.

[eriawan]

@nkolev92
thanks!
So what is the next update related to this issue? Will there any updates on the NuGet.exe client to fix this?
I'd love to submit PR to fix this, as this issue has been quite long time and it's still confusing.

[nkolev92]

We either remove the version list or try to be smarter about autogenerating it.
NuGet.exe will try to work with any MSBuild version available.

@eriawan Given that this is merely a string change, it's not super high on our bug list.

@NuGet/nuget-client Any ideas about what the string should be?

You can always create a PR changing the string, then we'll get someone from the team to help drive closure.

[obohaciak]

Hit the same exact issue today running NuGet CLI v 6.2.0.146

$ nuget help restore
NuGet Version: 6.2.0.146
usage: NuGet restore [ | <packages.config file> | ] [options]

-MSBuildVersion Specifies the version of MSBuild to be used with this command. Suppo
rted values are 4, 12, 14, 15.1, 15.3, 15.4, 15.5, 15.6, 15.7, 15.8,
15.9, 16.0. By default the MSBuild in your path is picked, otherwise
it defaults to the highest installed version of MSBuild.

$ nuget restore -MSBuildVersion 16
Cannot find the specified version of msbuild: '16'

$ nuget restore -MSBuildVersion 16.0
Cannot find the specified version of msbuild: '16.0'

$ nuget restore -MSBuildVersion '16.11.2.50704'
MSBuild auto-detection: using msbuild version '16.11.2.50704' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin'

$ nuget restore -MSBuildVersion 16.11
MSBuild auto-detection: using msbuild version '16.11.2.50704' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin'

[obohaciak]

@nkolev92 I understand it's not the most-urgent, but would be nice to get fixed. Right now this Github issue is among the top search results for this problem :) If you have already figured out the appropriate wording, can you please release the fix?

[nkolev92]

Hey @obohaciak

We don't really have a proposal for the wording here.
The list of versions NuGet can use tends to be whatever is available on the machine, but your mileage may vary depending on the imports your project has and that's simply something that NuGet can't know.

Basically, thinking in terms of what version of NuGet supports which verison of MSBuild is probably not the question, but rather what version of MSBuild can build your project.

NuGet occasionally uses features of newer msbuild, and usually the recommended way is matching NuGet to msbuild in a: MajorMSBuildVersion-11.MinorMsBuildVersion fashion.

So if NuGet.exe is 6.2, use 17.2 of MSBuild and vice versa.

[eriawan]

@nkolev92

What about my previous wording proposal?

Cannot find the specified version of msbuild '16.0'. 
The highest installed msbuild detected is '16.4', use this version explicitly or restore without MSBuildVersion as nuget will detect and use the highest installed of msbuild.

[nkolev92]

@eriawan
That's a good idea and something that could be added to improve the failure message when people do run into issues.

The supported versions listed part is weirder, that I'd almost prefer if they weren't listed in an exhaustive fashion. I think that'd address all concerns brought up in this issue.