TFS 2013 Build machine cannot see on-premises Nuget Feed

Question

I have read probably a hundred links online to try to find an answer, and I'm flat out of explanations.

I have a TFS 2013 Server running Git Team Projects. I create a TFS build to build a service which uses public (Entity Framework) nuget packages as well as a couple of our own libraries that are packaged as Nuget packages on an IIS server. I'm using Automatic Package Restore and NOT the 'deprecated' MSBuild "Enable Package Restore". Thus the only nuget file in the .nuget folder is nuget.config (which I've also tried moving into the root folder)

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
  <packageSources>
     <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
     <add key="myserver" value="http://myserver/Nuget/Nuget/" />
  </packageSources>
  <packageRestore>
     <add key="enabled" value="True" />
  </packageRestore>
</configuration>

The thing is, when I remote into the build box, and try this from a command-line:

nuget.exe list -source http://myserver/nuget/nuget

It does list all the packages.

But a TFS build, DOES pull down Entity Framework from nuget.org...but then it tries to build:

C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(1697,5): warning MSB3245: Could not resolve this reference. 
Could not locate the assembly "MyEntitiesLib". 
Check to make sure the assembly exists on disk. 
If this reference is required by your code, you may get compilation errors.

So, I'm at my wits end here. Both the project's nuget.config adn the default nuget.config in the msbuild tools folders have my source, I can list it from a command line, but Automatic Package Restore is NOT pulling that package down, and blowing up on compile.

Help anyone?

Could it be a security issue? The build server is probably running on another account then where you've tried the nuget command line from? — Wouter de Kort♦
You know, I thought about that. But the IIS Nuget site on premises is set to allow anonymous. There's no security on it at all. So I wouldn't expect the NT Active Directory account the TFS server is running under to have any problems getting it. There's also no firewall involved. Everything is on premises. If you have an idea for how I could easily check that I'd be interested in hearing it? I wish the log was more verbose and indicated what exactly TFS Build TRIED to do with regard to Nuget. — Randy Magruder
Is your Build account set to Network Service? That could give some problems but that's just a wild guess. I have to admit that I wouldn't know how to validate the permissions :( — Wouter de Kort♦
Have you tried adding the activePackageSource element to your config? And I would set automatic to true in your packagerestore element — Wouter de Kort♦
The "Application Tier Summary" Service account was indeed Network Service. Changed it to the same account I remote in with that has lots of access to things...It didn't seem to help. I don't know if I need to change anything else. How do you tell who the build agent is running as ? Maybe that's it? Can you you give me an example of the activePackageSource element and true flag the way you describe it? Thanks! — Randy Magruder

Randy Magruder Randy Magruder · Accepted Answer · 2014-11-25T19:59:30

The answer was to be found in the unlikeliest place.

Nuget fails to install specific version

I had built packages that had symbols versions side by side with non-symbols version, and nuget restore was obviously giving up on them. The hint was the warning about duplicate root nodes when I tried to run Nuget.exe Restore manually from the build box. I could list the packages, but I could not restore them. Once I deleted the *.symbol.nupkg files from the Nuget Repository, the packages were restored and the build worked properly.

Thank you to everyone. I hope this helps someone else out.

TFS 2013 Build machine cannot see on-premises Nuget Feed

1 Answers