Home: "NuGet restore" with NuGet 5.x doesn't pick the highest version of MSBuild.exe available

[xymunter]

When using the _NuGet_ build task with the _restore_ command in an Azure DevOps Server 2019 (ADOS) Build Pipeline after explicitly setting NuGet version to 5.x (and _Always check for new versions_ active) via_ _NuGet tool installer_ build task, the MSBuild.exe version that then is automatically picked is not the highest one, which would be 16.4, given that Visual Studio 2019 is intalled on the build machine.
Instead, the task log of the _NuGet_ build task states the following:

MSBuild auto-detection: using msbuild version '4.8.3761.0 built by: NET48REL1' from 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.

The documentation for the MSBuildVersion argument then states the following:

(3.2+) Specifies the version of MSBuild to be used with this command. Supported values are 4, 12, 14, 15.1, 15.3, 15.4, 15.5, 15.6, 15.7, 15.8, 15.9. By default the MSBuild in your path is picked, otherwise it defaults to the highest installed version of MSBuild.

As far as I understand the documentation, me expecting msbuild.exe version 16.4 to be used is not wrong.

I managed to find a workaround by using the _NuGet_ work task with the _custom_ command and using the -MSBuildVersion option with the version 16.4. That worked as expected, although my first attempt failed with the error message _##[error]The nuget command failed with exit code(1) and error(Cannot find the specified version of msbuild: '16')_ after setting the -MSBuildVersion option to 16, as the help text given in ADOS implied (for me, at least) that only the general version 16 was valid for this scenario.

The next step was to replace the -MSBuildVersion option with -MSBuildPath, in order to prevent the build from failing the moment a Visual Studio 2019 update is installed on the build machine.

Although this workaround seems to do the trick for us, I'd very much like to use the _NuGet_ build task using the _restore_ command instead of the _custom_ command.
Can you please point me in a direction how to achieve this?

[rrelyea]

msbuild /restore Foo.sln should work for you if you only use PackageReferences in your projects.
If you need packages.config support as well, starting in VS 2019 16.5-preview2 and later, msbuild /restore foo.sln will also support packages.config projects.

[xymunter]

Thank you for your answer.
I'm not 100% sure if I understand it, though.

The command you point out as solution is to be executed...where, exactly?
If it has to be set "manually" in the Build Task "NuGet" with "Custom" instead of "Restore" as a command type, the "only" improvement for me is to not having to specify a specific directory for msbuild.exe.

And yes, I need the solution for packages.config :)

I just realized that I wanted to update this post last week. Maybe this is also part of the solution to this particular issue.

We noticed that the PATH environment variable contained the "C:\Windows\Microsoft.NET\Framework64\v4.0.30319" path.

Further investigation showed that a colleague of mine introduced it to fix another problem we had (Error C1108: unable to find DLL: 'TLBREF.dll - another issue for another ticket, maybe) - and as it seems, there is no good alternative to using the PATH environment variable.

So as it seems, we're stuck with our current workaround which will stop to work with the next major version update of VS.

[VijayHugar]

@xymunter We also faced this issue after updating Nuget to latest version. It was referring to old MSBuild due to cache. So after setting the flag 'Disable local cache', it picked up latest MSBuild and task got succeeded. Please refer below screen shot for the flag.

[nkolev92]

Hey @xymunter

Did the advice from @VijayHugar help you?

NuGet.exe will prefer the MSBuild version in the path if at all set.
In 5.7, we're adding a -Latest switch that'll use the latest MSBuild available.

[xymunter]

Hey @nkolev92

As mentioned before, we kept using the workaround (as far as I'm aware of) and the whole issue moved out of my focus for some time.
We also coincidentally activated the _Disable local cache_ option due to another topic we encountered, so this should be fine.
I'll ask around if this works for us, and will close this ticket, if it does.

Thank you for all your help!