TeamCity building with MsBuild and NuGet: “Unable to connect to the remote server”

1
votes

I have setup my TeamCity to build using MsBuild a project that NuGet packages. During the build, the following command to install packages is issued, but fails:

..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server with exit code 1.

Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.

This is what I have done so far:

  • Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
  • Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
  • To provide the additinal paths ways to supply a path:
  • Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
  • Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)

What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?

Do you have any ideas of what to try?

1
c#msbuildteamcitynuget
I'm not sure if it will solve your problem or not but instead of running a command line nuget call have you tried using the NuGet Installer build runner? confluence.jetbrains.com/display/TCD8/NuGet+Installer – Paul Hunt

1 Answers

2
votes

The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.

I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.