VisualStudio.com (Visual Studio Team Services) builds failing on nuget package dependencies

4
votes

Thought I would try and get the most out of my visualstudio.com trial membership. I created a solution with a few projects, pushed it to the Microsoft git source control provider, configured a build definition and tried to build it on the project server. However it keeps failing telling me:

The type or namespace name 'Moq' could not be found (are you missing a using directive or an assembly reference?)

I know this means that the build server can't find the Moq.dll library. I had installed it using NuGet, but configured my .gitignore to keep the packages folder out of source control. I also enabled NuGet package restore for the solution and pushed nuget.exe, nuget.targets, and nuget.config (all 3 of the files in the .nuget folder) along with all of the other project files.

Now I am sure I could get the build to work if I pushed the packages folder too, but I want to keep the nuget packages folder out of source control. So I am wondering, is this possible? The visualstudio.com docs say that the build servers have visual studio 2013 installed, and because of this I assume that nuget package restore would work to download the missing dll's so that they can be resolved by MSBuild. Is this right? Or to use automated CI builds at visualstudio.com, do you need to have your packages under source control?

According to the log file, nuget package restore downloaded the package. What gives?

Project "C:\a\src\MySln.sln" (1) is building "C:\a\src\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj" (3) on node 1 (default targets). RestorePackages:
"C:\a\src.nuget\NuGet.exe" install "C:\a\src\Tests\MySln.ProjA.UnitTests\packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "C:\a\src\ " Restoring NuGet packages... To prevent NuGet from downloading packages during build, open the Visual Studio Options dialog, click on the Package Manager node and uncheck 'Allow NuGet to download missing packages'.
All packages listed in packages.config are already installed. PrepareForBuild: Creating directory "obj\Debug\". ResolveAssemblyReferences: Primary reference "Moq". C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets(1635,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Moq". 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\Tests\MySln.ProjA.UnitTests\MySln.ProjA.UnitTests.csproj]

This line is also in the build log file, below the above:

Considered "..\packages\Moq.4.1.1311.0615\lib\net40\Moq.dll", but it didn't exist.

2
msbuildcontinuous-integrationazure-devopsnuget-package-restore

2 Answers

3
votes

I had this same error but it was occurring on our build server. I had added Moq via NuGet, checked in the project and everything was fine. I then moved the project into a new folder in TFS and the build server just couldn't seem to find Moq. It was building great locally. I ended up fixing the problem by making sure all of my changes were checked into source control and then deleting my local source code directory. I got latest and my test project realized it needed a new copy of Moq. I blame TFS/ source safe or what ever the Visual Studio integration module is for not adding it to source control at some point in time.

2
votes

Figured this one out on my own. Turns out I had added the nuget packages before moving the test project into a Tests subfolder. The solution still built on my LM, probably because the dependencies were already copied to bin/Debug. After reinstalling the nuget packages, the solution built on vs.com.