In the following post, we will look at the difficulties in consuming packages from a different VSTS account, as part of a build process in our own account.
Background
Visual Studio Team Services (VSTS) offers package management services. As per the documentation, this is “an extension that makes it easy to discover, install and publish packages”. Team Services enables teams to collaborate with other teams through versioned, cohesive libraries and APIs, in the same way that many 3rd party vendors offer their libraries and frameworks today. In fact, VSTS Package Management exposes the most common package management services that developers use today – NuGet for .NET developers, NPM for NodeJS developers, and now in public preview, Java packages can be served as well.
Access to Packages
Unlike the public open feeds, your teams’ package managers are designed to enable access only to those accounts who should have access to the packages. When you create a new feed, VSTS asks you to decide who has permissions to contribute (i.e. publish to the feed), and who has access to read (i.e. download and consume packages from the feed):
You have two choices regarding the contribution of packages to the feed. You can specify that any of the team members (i.e. those who are members of the hosting team project) can add packages, and/or the build service account (i.e. the service account used to run builds in VSTS). Note that you will want to specify the latter if you use the build service to publish the packages (you should). You normally wouldn’t need to add permissions for the team members as well.
You also have two choices for controlling access to consumption of the feed as well. You can either limit access so that only members of the project can consume the feed’s packages, or you can allow everyone in the account.
This works fine for most organizations. Not for all, however.
Multi-Account Organizations
Some organizations own multiple VSTS accounts. For some the decision simply grew organically, with various teams trying out the services, and chose to stay this way because there is no easy migration path for a project from one account to another. Others intentionally decided to keep multiple accounts, one for each internal organization (different divisions, for example). Regardless of the reasons, the situation may arise, where components developed in and published by one account need to be consumed by components that are being developed in another account.
Unfortunately, this option does not exist. VSTS does not allow you to specify that you want to give access to members of another account.
How Can We Consume Packages from Another Account’s Feed?
The problem that we are trying to solve is the consumption of packages from Account A, in a build definition that builds an application under Account B. What we will need to do is to overcome the limitations that are set by VSTS’s package management services, and somehow access Account A, with a set of credentials that it will accept.
Solution
Step 1 – Access to the Publishing Account
The first thing you need to do, is to gain access to the account. You need credentials that allow you to view packages. This will be given to you by administrators of that account. You will be given a username, and a Personal Access Token, or PAT (see documentation about creating and using PATs). Your PAT will (ideally) be configured to grant you read access to Packaging for the required account.
Step 2 – Add a Custom NuGet Configuration File
Next, in order to customize how the build system restores NuGet packages, you are going to need to add a custom NuGet configuration file. You can set it up with the defaults, configuring whatever you might need for your own circumstances, like this:
Step 3 – Add Your Credentials to the Build Definition
Next, you will need to add the credentials for the package manager’s account to the build definition. You will store these as variables. Be sure to encrypt the PAT – you do not want any passwords to be saved in plaintext!
Step 4 – Add a Task to the Build Definition to Access the Package Feed
In the next step, you will need to create a custom source for accessing the other account’s feed. You will need a Command Line build task, and you will be running against the nuget.exe CLI tool. The simplest way to do this is to add nuget.exe to your source control. I prefer to put it under the solution, in a subfolder named Tools.
You will need to call the sources Add command, and specify the name of the feed, its URL, and the username and password/PAT. You will also specify which NuGet configuration file you are going to modify with this setting.
Note that you will want to set the name of the feed to be the same one that you specified in Visual Studio, when building your application.
Here is an example for the Arguments that you must set for the build service to recognize the other account’s feed:
sources Add -name OtherDivision -source https://assaf-account-b.pkgs.visualstudio.com/_packaging/PrimaryFeed/nuget/v3/index.json -user $(NugetUsername) -pass $(NugetPassword) -ConfigFile $(Build.SourcesDirectory)\Custom.nuget.config
Step 5 – Configure NuGet to Restore with Custom Configuration
Finally, you need to modify the NuGet restore command, so that it uses your custom configuration file:
Your build definition is now able to restore NuGet packages that are published by another Account!
Summary
In this blog post, you have learned how to configure NuGet in a VSTS build definition so that it can consume packages that are published by a different VSTS account.
I hope you find this useful.
Happy coding,
Assaf.
