Home: msbuild /t:restore behaves differently for BuildTools MSBuild than VS Enterprise MSBuild

Created on 16 Mar 2017  路  10Comments  路  Source: NuGet/Home

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):

NuGet version (x.x.x.xxx): 4

dotnet.exe --version (if appropriate): N/A

VS version (if appropriate): 2017

OS version (i.e. win10 v1607 (14393.321)): Win 10 1607 14393.693

Worked before? If so, with which NuGet version: 2.8.x

Detailed repro steps so we can see the same problem

  1. Run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\amd64\MSBuild.exe" /t:restore some.sln

  2. Compare results with "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\amd64\msbuild.exe" /t:restore some.sln

BuildTools is missing some nuget related things and #1 works while #2 does not. #2 complains of "target 'restore' does not exist" in the projects within solution.
...

VS.Client Duplicate Feature

Most helpful comment

We should add NuGet.Tools.vsix to build tools workload -- this will enable msbuild /t:restore, etc...

All 10 comments

I can't be certain the above is precisely the same issue that I encountered, but it seems to be similar/related, so I will add my notes:

While working on VSTS builds for Visual Studio 2017 (DotNetCore 1.1.1 sdk/tooling) we first installed vs2017 on a build agent. Due to the fact that we needed to authorize private VSTS NuGet package feeds we found that we needed to explicitly run NuGet.exe v4.0 to get our .sln and .csproj code to restore. (Like c:\nuget4\nuget.exe restore yada.sln)

We then tried to support the same build definition on another agent, this time using the vs2017 build tools installer (rather than the full visual studio install). Once we had the build tools installed, the nuget restore yada.sln would correctly infer msbuild 15's location, but would not find "anything to restore" in the sln. This same sln restore works perfectly in the agent with the full installation of visual studio 2017:

2017-03-16T18:42:22.3839157Z ##[section]Starting: nuget restore **/*.sln
2017-03-16T18:42:22.3869166Z ==============================================================================
2017-03-16T18:42:22.3869166Z Task         : NuGet Installer
2017-03-16T18:42:22.3869166Z Description  : Installs or restores missing NuGet packages
2017-03-16T18:42:22.3869166Z Version      : 0.2.29
2017-03-16T18:42:22.3869166Z Author       : Microsoft Corporation
2017-03-16T18:42:22.3869166Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613747)
2017-03-16T18:42:22.3869166Z ==============================================================================
2017-03-16T18:42:23.0600977Z [command]C:\Windows\system32\chcp.com 65001
2017-03-16T18:42:23.1201136Z Active code page: 65001
2017-03-16T18:42:23.5442197Z Detected NuGet version 4.0.0.2283 / 4.0.0
2017-03-16T18:42:23.5512220Z SYSTEMVSSCONNECTION exists true
2017-03-16T18:42:23.5512220Z [command]c:\program files\nuget\nuget.exe restore -NonInteractive c:\agent_a\_work\17\s\yada.sln
2017-03-16T18:42:24.1623732Z MSBuild auto-detection: using msbuild version '15.1.548.43366' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
2017-03-16T18:42:25.7617439Z Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
2017-03-16T18:42:25.8097542Z ##[section]Finishing: nuget restore **/*.sln

The working agent's build step output looks like this:

2017-03-15T15:37:52.6647134Z ##[section]Starting: nuget restore **/*.sln
2017-03-15T15:37:52.6647134Z ==============================================================================
2017-03-15T15:37:52.6647134Z Task         : NuGet Installer
2017-03-15T15:37:52.6647134Z Description  : Installs or restores missing NuGet packages
2017-03-15T15:37:52.6647134Z Version      : 0.2.29
2017-03-15T15:37:52.6647134Z Author       : Microsoft Corporation
2017-03-15T15:37:52.6647134Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613747)
2017-03-15T15:37:52.6647134Z ==============================================================================
2017-03-15T15:37:53.1021908Z [command]C:\Windows\system32\chcp.com 65001
2017-03-15T15:37:53.1178167Z Active code page: 65001
2017-03-15T15:37:53.4303004Z Detected NuGet version 4.0.0.2283 / 4.0.0
2017-03-15T15:37:53.4459473Z SYSTEMVSSCONNECTION exists true
2017-03-15T15:37:53.4459473Z [command]c:\nuget\nuget.exe restore -NonInteractive c:\agent_A\_work\5\s\Yada.sln
2017-03-15T15:37:53.8990293Z MSBuild auto-detection: using msbuild version '15.1.548.43366' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\bin'.
2017-03-15T15:37:57.1020687Z Restoring packages for c:\agent_A\_work\5\s\src\Yada\Proj1.csproj...

SNIP

2017-03-15T15:38:06.8675531Z Restore completed in 580.72 ms for c:\agent_A\_work\5\s\src\Yada\Proj1.csproj.
2017-03-15T15:38:07.3206983Z Committing restore...
2017-03-15T15:38:07.3363039Z Restore completed in 544.3 ms for c:\agent_A\_work\5\s\src\Yada\Proj2.csproj.
2017-03-15T15:38:07.3363039Z 
2017-03-15T15:38:07.3520581Z NuGet Config files used:
2017-03-15T15:38:07.3520581Z     c:\agent_A\_work\5\s\NuGet.Config
2017-03-15T15:38:07.3520581Z     C:\Users\yada\AppData\Roaming\NuGet\NuGet.Config
2017-03-15T15:38:07.3520581Z     C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
2017-03-15T15:38:07.3520581Z 
2017-03-15T15:38:07.3520581Z Feeds used:
2017-03-15T15:38:07.3520581Z     https://itron.pkgs.visualstudio.com/_packaging/Yada/nuget/v3/index.json
2017-03-15T15:38:07.3831782Z ##[section]Finishing: nuget restore **/*.sln

Again, this could possibly be some other agent configuration nuance, and we have the workaround of just installing the full visual studio on our build agent, but I really would expect this to have been functionally equivalent...

Update: After finishing a vs2017 install (Community Edition) on the failing agent, the restore started working again. There definitely is a discrepancy between VS install and BuildTools Install.

Yep, I saw in the file system that the BuildTools does not install the NuGet related targets. There are also a lot of other targets that I found that were missing in BuildTools (deploy related ones). Furthermore, if you have config transforms, you'll also need to install the Windows SDK to get aspnet_merge.exe to properly work.

We should add NuGet.Tools.vsix to build tools workload -- this will enable msbuild /t:restore, etc...

Is there a workaround to this? Can a NuGet targets file be placed somewhere in the MSBuild install folder so that msbuild /t: restore works?

I think there is https://github.com/NuGet/Home/issues/3660 already.
Even if restore worked with the build tools, they also don't contain the SDKs so you can't build the projects anyway (without modifying MSBuildSDKsPath) https://github.com/Microsoft/msbuild/issues/1697

@kraigb my workaround was to copy the entire NuGet directory
from DEVPC:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet
to BUILDMACHINE:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet

Anyone got an update on this? Is the best workaround still to copy files from a dev machine with VS 2017 installed? Thanks!

@jamescrowley This is fixed in the latest Visual Studio 15.4 release that went out yesterday, 9 October 2017.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vsfeedback picture vsfeedback  路  3Comments

dotMorten picture dotMorten  路  3Comments

skofman1 picture skofman1  路  3Comments

jainaashish picture jainaashish  路  3Comments

LordMike picture LordMike  路  3Comments