23
votes

I'm trying to get our TFS2015 Build (TFSBuild vnext) going along with VS Team Services.

Thus far most blogs and documentation has been helpful, except for when trying to build a project that uses custom package sources for NuGet automatic package restore.

I've successfully deployed an a Team Services Build Agent (the new mechanism for builds) and all seemed to go well until the build task to Restore NuGet packages failed.

The failure was due to custom/private package source not being picked up from the installed VS configuration, so those packages could not be found. The traditional packages from the default NuGet package feed did restore without issue.

How do I specify the additional package sources for NuGet to use when using an agent?

EDIT: vcastro asked about the NuGet Installer build step and defining paths in the configuration of that build step. The above is using the Visual Studio Build step and the integrated option to have NuGet restore packages. Refer this image for reference: http://i.imgur.com/Hrqhhk2.png

8
Why not just create a NuGet server to host your custom packages?Andrew Clear
That's what we are doing. The issue is how to have NuGet (when being run by the new TFS 2015 Build agent) know NuGet about the new package source(s). This is what the NuGet.Config is for, but it's not picking it up from the local folders and only the User/Service profile paths (see answer below).Jaans
Did you specify the path to your nuget.exe (where you have your custom nuget.config) in the Nuget Installer Task's advanced settings? We also had this problem until we pointed the build task to our own nuget.exe and nugget.config.vcastro
@vcastro Nope. It's actually using a Visual Studio Build step (we have other VS specific dependencies) and this build step has an option to restore NuGet packages. Will update the question with that key detail - thanks.Jaans
I understand, but why can't you just turn that option off and add a previous step to restore nuget packages?vcastro

8 Answers

17
votes

Alternatively you could also add a NuGet Installer build step before the Visual Studio Build step in your build configuration to restore all NuGet packages.

There you can pass the location of your private repo as argument to nuget.exe:

-source "https://www.nuget.org/api/v2/;http://mynugetserver"

7
votes

I've scrounged the web with little success, but after fiddling the following will help:

OK It seems that the package sources configured for NuGet.config is stored per user account, e.g.

c:\Users\<<username>>\AppData\Roaming\NuGet\NuGet.config

My issue was harder to resolve, because the build agent was running as a Windows Service under the Local System account. So to get NuGet configuration to for the build, I had to use the following path instead:

  • 64-bit Windows C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config
  • 32-bit Windows C:\Windows\System32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config

You may need to have elevated permissions in order to create the NuGet subfolder and NuGet.Config file.

Note: I have no solution for using the Local Service account. The above only works for the Local System (or an actual user) account.

7
votes

Add a NuGet.config to your project that specifies an alternate package location. The rules for resolution are well-defined and explained in the official documentation.

7
votes

There is a new VSTS Task called "NuGet Installer" this allows you to check in your NuGet.config file and specify the different package sources. Run this task before you run MSBuild.

If you are using the VSTS NuGet Feed you will need to add the build service account to the feed to enable downloading of packages https://www.visualstudio.com/get-started/package/use/common-identities

enter image description here

2
votes

One solution (works for me) is change account for tfs 2015 build agent service (on my build machine VSO Agent tsf.Agent-PC) to tfsagent, for example, and add Nuget.config to the C:\Users\tfsagent\AppData\Roaming\Nuget. That's all!

1
votes
  1. Specify your custom NuGet feed URL’s in the solution’s nuget.config file. Do not store any usernames & passwords in this file.

    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="MyCompany" value="https://nuget.mycompany.com:443/nuget" />
    
  2. Create username & password variables in your build definition in VSTS. Variables can be encrypted and will not be displayed in any of the build log outputs. Here I'll create MyCompanyNugetUser and MyCompanyNugetPwd variables.

  3. In our build steps, we add a Powershell script as the first action, this will read the username & password variables and update the user level nuget.config file on the build machine. Below is the code snippet from my inline Powershell script:

    Arguments:

    $(MyCompanyNugetUser) $(MyCompanyNugetPwd)
    

    Script:

    param($user, $pwd)
    
    $nugetFile = "$ENV:AGENT_HOMEDIRECTORY\agent\worker\tools\nuget.exe"
    Write-Output "Looking for nuget.exe in $nugetFile"
    
    if (-not (Test-Path $nugetFile))
    {
      Write-Error "nuget.exe could not be located."
      return
    }
    
    Write-Output "nuget.exe located"
    
    $cmd = "$nugetFile sources add -name MyCompany -source https://nuget.mycompany.com:443/nuget -username $user -password $pwd -StorePasswordInClearText"
    Write-Output $cmd
    iex $cmd
    
  4. Next, we just continue to execute the default NuGet Restore step from Microsoft’s templates

More here: https://codingcase.com/2016/07/27/vsts-build-setup-custom-nuget-feeds-with-authentication/

HTH

0
votes

In the RTM of Team Foundation Server 2015 you have to add a build step of the type "NuGet Installer", and restore the packages of the Solution file before you run the actual build process. In this task you can pass the argument -ConfigFile path/to/nuget.config which contains your repository path.

For Example:

<configuration>
  <packageSources>
    <add key="Internal Nuget" value="\\srv-nuget\Repo" />
  </packageSources>
</configuration>

enter image description here

-1
votes

If you are having trouble getting this to work on UWP ONLY, then ensure that you have the CASE of the package name spelt correctly. If the case is wrong, then (for UWP only) our build server fails the build.

for instance, if you have a package called Com.Company.Components and update the package using "install-package com.company.components" (note the case of the initial letter) then the UWP build on the build server may fail to find the package in your local store.