Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

dmarlow opened this issue Mar 16, 2017 · 10 comments
Product:VS.Client Resolution:Duplicate This issue appears to be a Duplicate of another issue Type:Feature


Copy link

dmarlow commented Mar 16, 2017

Details about Problem

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

NuGet version ( 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.

Copy link

automatonic commented Mar 16, 2017

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](
2017-03-16T18:42:22.3869166Z ==============================================================================
2017-03-16T18:42:23.0600977Z [command]C:\Windows\system32\ 65001
2017-03-16T18:42:23.1201136Z Active code page: 65001
2017-03-16T18:42:23.5442197Z Detected NuGet version / 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](
2017-03-15T15:37:52.6647134Z ==============================================================================
2017-03-15T15:37:53.1021908Z [command]C:\Windows\system32\ 65001
2017-03-15T15:37:53.1178167Z Active code page: 65001
2017-03-15T15:37:53.4303004Z Detected NuGet version / 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...


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.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 Feeds used:
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...

Copy link

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.

Copy link

dmarlow commented Mar 16, 2017

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.

Copy link

rrelyea commented Mar 20, 2017

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

Copy link

kraigb commented May 3, 2017

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?

Copy link

dasMulli commented May 3, 2017

I think there is #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) dotnet/msbuild#1697

Copy link

schalpat commented May 4, 2017

@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
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\CommonExtensions\Microsoft\NuGet

@rrelyea rrelyea modified the milestones: 4.4, 4.3 Jun 26, 2017
Copy link

jamescrowley commented Oct 9, 2017

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

Copy link

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

Copy link

Dupe of #5562

@nkolev92 nkolev92 added the Resolution:Duplicate This issue appears to be a Duplicate of another issue label Oct 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Product:VS.Client Resolution:Duplicate This issue appears to be a Duplicate of another issue Type:Feature
None yet

No branches or pull requests

7 participants