TFS Can't Restore NuGet Package - tfs

Question

I've got TFS doing some continuous integration builds. Today, it broke for one solution. It seems it can't find AutoMapper. All the other packages can be found just fine.
A couple relevant points:
None of the packages are in source control, we're letting TFS restore them.
We have an internal NuGet feed, but it doesn't seem to be a problem in other solutions, and in this solution we are still getting Entity Framework to restore - just not AutoMapper.
I tried removing and re-adding the NuGet Packages. No luck.
If I use Remote Desktop to connect to the build server and open the project in Visual Studio there, it restores the packages and builds fine.
I can build manually by executing D:\"Program Files"\"Microsoft Team Foundation Server 12.0"\Tools\Nuget.exe restore followed by msbuild MySolutoin.sln
Our TFS server is installed on our D:\ drive.
This is from the TFS Logs:
D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\nuget.exe restore "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" -NonInteractive
Installing 'EntityFramework 6.1.3'.
Installing 'InternalPackage 1.0'.
Successfully installed 'InternalPackage 1.0'.
Successfully installed 'EntityFramework 6.1.3'.
Unable to find version '3.3.1' of package 'AutoMapper'.
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\MSBuild.exe /nologo /noconsolelogger "C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln" /nr:False /fl /flp:"logfile=C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.log;encoding=Unicode;verbosity=normal" /p:SkipInvalidConfigurations=true /m /p:OutDir="C:\Builds\1\MyCompany Web\FclQuoteWcfService\bin\\" /p:VCBuildOverride="C:\Builds\1\MyCompany Web\FclQuoteWcfService\src\FclQuoteWcfService.sln.vsprops" /dl:WorkflowCentralLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;BuildUri=vstfs:///Build/Build/230;IgnoreDuplicateProjects=False;InformationNodeId=12;TargetsNotLogged=GetNativeManifest,GetCopyToOutputDirectoryItems,GetTargetPath;TFSUrl=http://ctidev2k8:8080/tfs/MyCompany;"*WorkflowForwardingLogger,"D:\Program Files\Microsoft Team Foundation Server 12.0\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll";"Verbosity=Normal;" /p:BuildId="9aa9f8af-c9b9-4d0a-ba06-7cc959231d8e,vstfs:///Build/Build/230" /p:BuildLabel="FclQuoteWcfService_20150330.2" /p:BuildTimestamp="Mon, 30 Mar 2015 20:40:07 GMT" /p:BuildSourceVersion="LFclQuoteWcfService_20150330.2#$/MyCompany Web" /p:BuildDefinition="FclQuoteWcfService"
Exception Message: MSBuild error 1 has ended this build. You can find more specific information about the cause of this error in above messages. (type BuildProcessTerminateException) Exception Stack Trace: at System.Activities.Statements.Throw.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Answer 1

I've seen this too. It seems to be triggered as soon as NuGet package restore switches to the internal feed. Once it does this is doesn't switch back to the official nuget.org feed and continues to look for the packages on the internal feed.
Ensure both package sources are added to your NuGet.config file. Also ensure both sources are 'active'.
<configuration>
<packageSources>
<add key="nuget.org"
value="https://www.nuget.org/api/v2/" />
<add key="example.com"
value="http://example.com/feed/nuget/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
See NuGet configuration file documentation.

Answer 2

Matt's answer put me on the right track but we don't use an internal feed so I had to do some more digging. This answer works, at least, for a project created in Visual Studio 2015 and built by TFS 2015.
In Visual Studio, open the NuGet package manager settings (Tools menu > NuGet Package Manager > Package Manager Settings). Choose "Package Sources" from the options list on the left.
Create the nuget.config file at the root of the solution. This should be the same folder location as your ".sln" solution file. Copy the following into the config file:
<configuration>
<packageSources>
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
Within the <packageSources> tag, create an <add key="" value="" /> entry for each source listed in the "Package Sources" options window. The key is the name of the source as shown above the URL, and the value is the URL itself. Include those listed in both "Available package sources" and "Machine-wide package sources". I did not create an entry for the local filesystem as it wasn't used in this solution. Based on the screenshot above, the complete config file now contains the following:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org"
value="https://api.nuget.org/v3/index.json" />
<add key="Microsoft and .NET"
value="https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/" />
</packageSources>
<activePackageSource>
<add key="All"
value="(Aggregate source)" />
</activePackageSource>
</configuration>
After committing the nuget.config file to source control, TFS was able to download all the necessary NuGet packages and successfully build the solution.

Answer 3

In addition to Matt's answer, I'd like to highlight the following well-hidden stuff from the NuGet documentation:
NuGet config files are treated in the following priority order
(closest to the folder nuget.exe runs from wins), for example assuming
the solution directory is c:\a\b\c:
c:\a\b\c\.nuget\nuget.config - This file is only used for solution
level packages, and is not supported in nuget 3.0 - 3.4
c:\a\b\c\nuget.config
c:\a\b\nuget.config
c:\a\nuget.config
c:\nuget.config
User specific config file,
%AppData%\NuGet\nuget.config.
Or the user specified file thru option
-ConfigFile.
This could explain some weird behaviour in specific scenario's where a restore does or does not pick up a configured feed, depending on whether youre restoring with nuget 2.x or 3.x
Edit: and I found yet another reason why packages might not be detected:
I have package "A" with version 1.1.1.0 .
Prior 3.4 this command works well:
nuget install A -version 1.1.1.0
With NuGet 3.4 RC I get:
An error occurred while retrieving package metadata for 'A.1.1.1' from
source 'N'. An error occurred while retrieving package metadata for
'A.1.1.1' from source 'N'. Data at the root level is invalid. Line
1, position 1.
...
The client treats 1.1, 1.1.0, 1.01.0 and 1.1.0.0 as the same version
using SemVer rules. The reason non-normalized versions were special
cased in the past is because for v2 http calls the client would first
send the version string exactly as the user specified it