Home: Nuget MSBuild auto-detection picks up msbuild.exe from Microsoft SQL Server Data Tools for VS 201

[maciakon]

After installing Microsoft SQL Server Data Tools for Visual Studio 2017, nuget.exe picks up msbuild.exe from incorrect path.

Details about Problem

NuGet product used:
NuGet.exe 4.9.3.5777
Visual Studio: 15.9.7
Microsoft SQL Server Data Tools for Visual Studio: 15.9.7

Detailed repro steps so we can see the same problem

1. Install Visual Studio Professional 2017 (15.9.7)

2. Install Microsoft SQL Server Data Tools for Visual Studio 2017 (15.9.7)

3. Run nuget.exe -restore on a *.sln file.

4. nuget.exe output:
   MSBuild auto-detection: using msbuild version '15.9.21.664' from 'C:Program Files (x86)Microsoft Visual Studio2017SQLMSBuild15.0bin'

5. Expected behavior:
   MSBuild auto-detection: using msbuild version '15.9.21.664' from 'C:Program Files (x86)Microsoft Visual Studio2017ProfessionalMSBuild15.0Bin'

6. Due to incorrect msbuild location detected, restore command ends with MSB4019 error:
   error MSB4019: The imported project "C:Program Files (x86)Microsoft Visual Studio2017SQLCommon7IDEVCVCTargetsMicrosoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Additional comment:

Following script using vswhere finds msbuild in correct path:

@echo off
setlocal enabledelayedexpansion

for /f "usebackq tokens=*" %%i in (`vswhere -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe`) do (
  echo "%%i"
  exit /b !errorlevel!
)

Output:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\B
in\MSBuild.exe"

[desjoerd]

Hello, we are also facing this issue in combination with Azure DevOps, is there a workaround for this?

[richardzaat]

Same issue here. We have VS2017 installed, and later installed SSDT.
When running the build on our Azure DevOps private pipeline, nuget uses the SSDT MSBuild instead of the VS2017 one (enterprise). Please fix as this is now causing issues of webapplication targets not found (and more targets actually)

[richardzaat]

@maciakon Have you been able to find a workaround in the mean while? If so, please share.

[maciakon]

@richardzaat No, I have just removed SSDT from the build machine.

[richardzaat]

@maciakon

Seems that this will not be solved until Nuget 5.3 version.
Work around: add the path to your latest MSBuild bin directory to the PATH, then restart the Azure DevOps agent. E.g. add D:Program Files (x86)Microsoft Visual Studio2017EnterpriseMSBuild15.0Bin to the PATH variable.

Nuget first searches the PATH and then checks C:Program files (x86) and all its subfolders for the msbuild.exe

[kartheekp-ms]

nuget.exe behavior to pick MSBuild path is explained in #7621. MSBuild path can also be passed as argument to the restore command which gets higher precedence over PATH environment variable setting (see doc). Adding @nkolev92 @zivkan @rainersigwald for suggestions.

[nkolev92]

As Kartheek suggested, the behavior is expected.
In the OP situation, I'd imagine both MSBuild instances are the exact same version, is that right?

There are probably situations in which SSDT MSBuild being selected is the correct one.

Maybe there's a way to make NuGet prefer the enterprise SKU instead of SSDT?
While that'd be more likely to succeed scenario, it could be a breaking change for some customers.