The private NuGet package feed included with Visual Studio Team Services provides a straightforward way to distribute proprietary NuGet libraries for use by multiple .NET applications within your organization without publishing your sensitive proprietary library publicly over the internet for all to use. Microsoft provides good documentation for how to do this in Windows, but I had to do some digging and troubleshooting in order to get it working in Linux. Once you figure it out it’s fairly simple, but at the time of writing there’s no simple “How To” guide which can be found easily via Google. The magic secret sauce lies within the dotnet cli. Microsoft’s documentation leads one to believe that the NuGet CLI is the way to go by listing instructions for NuGet 2 and Nuget 3, which threw me off at first: neither of these worked out of the box for me in Linux. NuGet 3 is not currently available for Linux, and the Windows version didn’t work for me through Wine. The NuGet 2 CLI is available for Linux from Microsoft, but following Microsoft’s instructions for using NuGet 2 doesn’t work out of the box either. When using the version of NuGet packaged within the dotnet cli, however, it works perfectly once you’ve got your credentials configured properly. For archival and compatibility purposes, this guide was written for a .NET Standard 2.0 library built from Ubuntu 18.04. Obviously these techniques might vary for different versions of the .NET Standard or for different distros.

Step 1: Create And Build Your Library

We’ll start off by creating our NuGet library up to the point of building the library and packing your *.nupkg file. This is fairly straightforward and is covered pretty concisely here, so I won’t retread this ground. The main other thing to note is that you’ll want your library to target the appropriate version of .NET Standard for your needs, rather than directly targeting .NET Core or the full .NET Framework, in order to achieve compatibility with the corresponding versions of both .NET Core and traditional .NET.  For example, if you want your library to be consumable by both .NET Core 2.0 applications and .NET Framework 4.6.1 applications, then you would target the .NET Standard 2.0.

Step 2: Set Up Your Workstation-Level Credential Configuration

Next we’ll need to store your Visual Studio Personal Access Token in the global NuGet.Config used by the dotnet cli  so that it can authenticate with VSTS to access your package feed. Strictly speaking we could also do this in the NuGet.Config within your solution, but we’re not going that route because it’s a terrible idea to check your PAT into source control for obvious reasons: anybody else who has access to the code now or in the future can use the PAT to authenticate as you! We’ll do this by updating the NuGet config located at ~/.nuget/NuGet/NuGet.Config (C:\Users\username\AppData\Roaming\NuGet in Windows) to follow this example:

<xml version="1.0" encoding="utf-8">
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="YourFeedKey" value="https://yourorganization.pkgs.visualstudio.com/_packaging/Your.Feed/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <YourFeedKey>
      <add key="Username" value="personalaccesstoken" />
      <add key="ClearTextPassword" value="PAT generated by VS Online Goes Here" />
    </YourFeedKey>
  </packageSourceCredentials>
</configuration>

Under packageSources, you’ll need to add an entry for your VSTS package feed. You can use whatever you want for your feed key. For the value, you’ll use the feed URL given by VSTS in the “Connect To Feed” window in the Package Management section. This is the “Package Source URL” mentioned in this article. Under packageSourceCredentials, you’ll need to add a section named after the key of the packageSource in the previous section (YourFeedKey in this example). The Username must be provided, but it can be anything. For the ClearTextPassword field, you’ll need to provide a VSTS-generated Personal Access token, which is described here. It will require the Packaging (read, write, and manage) scope.

Step 3: Publish To VSTS

Packages can be published to NuGet via dotnet cli using the following command:

dotnet nuget push packagetopublish.nupkg -k VSTS -s feedurl

For example, a publish of our example package to our example VSTS NuGet feed where we’re upgrading from 0.0.1 to 0.0.2 would look like this:

dotnet nuget push bin/Debug/ExampleLibrary.0.0.2.nupkg -k VSTS -s https://yourorganization.pkgs.visualstudio.com/_packaging/Your.Feed/nuget/v3/index.json

Alternatively under Windows you can use the NuGet cli and bundled credential manager as documented here.

Step 4: Configure Your Library-Consuming Projects To Access Your Package Feed

Any project that you want to consume your library with will need to be configured to read the corresponding VSTS feed. If you’re using the full Visual Studio in Windows you can simply follow the directions here. If you’re using Visual Studio Code, create a NuGet.config file anywhere in your project if one doesn’t already exist. Under configuration.packageSources, add a new key entry for the feed that you want to configure. It should follow this example:

<configuration>
    <packageSources>
        <add key="NuGet.org" value="https://api.nuget.org/v3/index.json" />
        <add key="YourFeedKey" value="https://yourorganization.pkgs.visualstudio.com/_packaging/Your.Feed/nuget/v3/index.json" />
  </packageSources>
</configuration>

Note that the feed configuration is the same line as in your global config. Also note that there’s intentionally no credential information because we intend to check this file into source control.

Step 5: Install The Published Packages From Your Library-Consuming Projects

To install the published package, simply run run the following:

dotnet add package ExampleLibrary

Since you’re running it from the dotnet cli, it should pull your feed info from your global NuGet.Config and pull your package through your VSTS feed. When you need to upgrade to a newer version of your library, simply update the version number of the corresponding PackageReference manually in your *.csproj file and run dotnet restore.

<PackageReference Include="ExampleLibrary" Version="0.0.3"/>

To do this in the full Visual Studio, follow Microsoft’s directions here.