6

I am really going nuts here with nuget and building a solution under Visual Studio Team Services (visualstudio.com). Any help will be much appreciated.

I have a solution containing 36 projects. Many projects use the same 5 or 6 nuget packages. I have carefully followed instructions for Migrating MSBuild-Integrated solutions to use Automatic Package Restore and therefore have a .nuget folder under my solution folder which contains a sole NuGet.Config file and no longer contains Nuget.exe or Nuget.targets files. All projects have had their Nuget.targets lines removed.

I am using Visual Studio 2013 Professional (v12 Update 2) and the solution builds locally without errors or warnings. Even after a Clean and deletion of the packages folder it downloads and builds fine. The packages folder is NOT checked into Visual Studio Team Services.

Examining the build log suggests that:

  1. nuget did not kick in at the start of the Build in order to check for, download and unpack any unresolved packages (it was doing this before migrating from MSBuild-Integrated to Automatic Package Restore - however despite that, it wasn't able to resolve references)
  2. I am left with 113 errors, centred around the fact that projects were unable to resolve references.
  3. Unlike a local build (and MSBuild-Integrated), Visual Studio Team Services now doesn't even mention nuget in its build log!!!

An example of the log where things start to fail (although this is obviously because nuget hasn't stepped in):

Project "C:\a\src\TFS\RSPlatform\Main\Source\RSPlatform Team Project.sln" (1) is building "C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\A2Refresh.csproj" (8) on node 1 (default targets).
PrepareForBuild:
  Creating directory "obj\Release\".
ResolveAssemblyReferences:
  Primary reference "Bytescout.Spreadsheet".
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Bytescout.Spreadsheet". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\A2Refresh.csproj]
          For SearchPath "C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\FakesAssemblies".
          Considered "C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\FakesAssemblies\Bytescout.Spreadsheet.winmd", but it didn't exist.
          Considered "C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\FakesAssemblies\Bytescout.Spreadsheet.dll", but it didn't exist.
          Considered "C:\a\src\TFS\RSPlatform\Main\Source\Support\A2Refresh\FakesAssemblies\Bytescout.Spreadsheet.exe", but it didn't exist.
          For SearchPath "{HintPathFromItem}".
          Considered "..\..\packages\Bytescout.Spreadsheet.2.4.0.1346\lib\net45\Bytescout.Spreadsheet.dll", but it didn't exist.
          For SearchPath "{TargetFrameworkDirectory}".
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Bytescout.Spreadsheet.winmd", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Bytescout.Spreadsheet.dll", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Bytescout.Spreadsheet.exe", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\Bytescout.Spreadsheet.winmd", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\Bytescout.Spreadsheet.dll", but it didn't exist.
          Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\Bytescout.Spreadsheet.exe", but it didn't exist.
          For SearchPath "{Registry:Software\Microsoft\.NETFramework,v4.5.1,AssemblyFoldersEx}".
          Considered AssemblyFoldersEx locations.
          For SearchPath "{AssemblyFolders}".

Can anyone advise how I should get Visual Studio Team Services to use nuget? How is Visual Studio Team Services even suposed to use NuGet if Automatic Package Restore suggests dropping ~/.nuget/NuGet.exe?

Thanks in advance, Chris

Esther Fan - MSFT
  • 8,276
  • 4
  • 27
  • 25
Chris Walsh
  • 3,423
  • 2
  • 42
  • 62
  • Did you ever figure this out? I've got about 12 hours into trial and error on this with no luck. The link in the answer says that the default workflows for VSO should already handle this, but I've opened them up and confirmed that nuget package restore is not implemented. – The Muffin Man Jul 14 '14 at 14:40
  • Hi The Muffin Man, I've not. @probackpacker's response did help in getting nuget to kick start and perform the package restore process, HOWEVER, when it goes on to build the solution/projects, the relevant projects still cannot locate the assemblies. See my log file (Jun 26th at 9:09) for how far I've got. – Chris Walsh Jul 14 '14 at 19:46
  • This is **not** okay. I'm sitting with a very much simpler set up than your 30+ projects and I still can reproduce this stupid misbehavior! I have a console application with one (1!) file, *Program.cs*. All's working great until I add anything from NuGet - I tried EF and nUnit. Then - poof! Nothing goes through anymore. I don't think it's impossible to resolve, just a very stupid setup by MS. Any hints? – Konrad Viltersten Jan 16 '16 at 11:37

3 Answers3

4

If you are building on Visual Studio Team Services then I have found that both Nuget.exe and Nuget.targets need to be present, which seems to be contrary to all the advice you can find by googling this subject.

Adding them in got my Visual Studio Team Services builds working.

Esther Fan - MSFT
  • 8,276
  • 4
  • 27
  • 25
IntoNET
  • 456
  • 2
  • 14
  • I'm sure I've tried that option too but I will go back and give it a go and report back. At minimum, it might output something different in the log file which I can then feedback here. – Chris Walsh Feb 05 '15 at 22:14
  • Do you have a build.proj file for the solution? – IntoNET Feb 05 '15 at 22:32
  • I will have a look and provide it if I do. – Chris Walsh Feb 05 '15 at 22:59
  • 1
    After searching for 2 hours, this fixed it for me. Just needed to check in nuget.exe – Greg Mar 16 '15 at 06:53
  • I was having the same problem as the OP after following all of the provided instructions to the letter. In the end checking in nuget.exe fixed the problem. I didn't need to include a .target file. – BenC3 Apr 30 '15 at 11:07
  • @Greg and IntoNET: What exactly do you mean by "*check in nuget.exe*" and "*Nuget.exe needs to be present*"? Are we talking about a checkbox that needs to be checked (set to true) somewhere in the portal for VS Online or are we talking about the actual file that needs to be deposited in the repository? Where in the directory structure on my local machine should it reside? I don't check in MsBuild.exe nor should I... Weird with NuGet.exe... – Konrad Viltersten Jan 16 '16 at 11:51
  • You need to add nuget.exe and nuget.targets into your source code repository, at the same location as it appears in your solution. it seems counter-intuitive to add binaries into version control, but since the Visual Studio Team Services build controller doesn't have every NuGet package installed on it, you need to help it along a bit. – IntoNET Jul 14 '16 at 09:27
2

After trying many things I found that I was using the wrong default template.

I was using:

DefaultTemplate.11.1.xaml

The Correct template for me was:

TfvcTemplate.12.xaml

When I used this template the build restored from nuget and completed correctly

Mark W
  • 705
  • 1
  • 9
  • 20
1

I have not used Visual Studio Team Services, but the NuGet docs claim that Package Restore should be part of the build process by default

For Team Foundation Build 2013 on-premises and Visual Studio Online (formerly Team Foundation Service), the default Build Process Templates already implement the NuGet Package Restore workflow without any special configuration. The following information only applies to Team Foundation Build 2012 and earlier, or to Build Process Templates that have been customized and had the NuGet Restore functionality removed.

If for some reason your build process does not include this step (as appears to be the case) you may need to add it manually. This blog post details how to use package restore with Team Services. It uses a dedicated build file and the process described in the previous link.

Esther Fan - MSFT
  • 8,276
  • 4
  • 27
  • 25
Michael Richardson
  • 4,213
  • 2
  • 31
  • 48
  • Hi probackpacker. I've just got back from holiday this evening. Initial look at your answer looks promising but I'm going to find some time to read the links you provided and get it clear in my head. I'll report back once I've done this. Cheers. – Chris Walsh Jun 22 '14 at 23:11
  • I've read the very useful blog post you've provided me and added NuGet.exe to a tools folder and created an msbuild project that does the NuGet restore prior to building the solution. I can see the packages getting restored now, however for some insane reason, the main compile is still not able to resolve the assemblies! Unfortunately, even on a DETAILED build log, the path to where the packages are built to are is not explicitly reported. I've tried changing my msbuild.proj's "outdir" but still not getting resolution occurring. Any ideas? Thanks. – Chris Walsh Jun 26 '14 at 08:56
  • Here is my build log: https://dl.dropboxusercontent.com/u/26079253/build%28C874%29.log – Chris Walsh Jun 26 '14 at 09:09
  • @ChrisWalsh I've followed that too. Same result. It seems that the original issue is that the builder can't find the NuGet packages. We assumed that it was because they failed to be restored. **However**, it could also be because they're present but that the server doesn't have the correct path to hem! I can see in my log that they're being copied over. So adding the step for explicit restore solves a problem we don't have. Then, the build fails for the same reason (restore form NuGet **twice** but not set the path right). I'm very close to switching to TeamCity right now... – Konrad Viltersten Jan 16 '16 at 11:57