NuGet Package Restore from a secured feed
One of the most frequently asked questions at MyGet is the following one (we have pending updates to our FAQ section):
How do I set up NuGet package restore against a private MyGet feed requiring authentication?
This is also one of the things you might end up doing when debugging NuGet package restore issues.
For public feeds, you only need to change the repository URL in the nuget.targets file to let your build server know from where it needs to fetch the packages. For private feeds however, there are a few things you need to know.
Which credentials should I use?
At MyGet, we recommend you to create a separate account for your build agents and give it specific permission on your feed (e.g. readonly or read/write, but no additional permissions).
It is not a technical requirement though: you could simply use your personal account, but please be aware that in this case you share your credentials!
As you'll see in this post, you can store the credentials for the build service account on the build agent(s) without having to share them with anyone. Using a user's account for the build agent can break anyone's build if access for this user is revoked...
Visual Studio will prompt for credentials
As soon as you try to communicate with a secured package source in Visual Studio, it will prompt you for credentials.
So why do you get the following build error when using package restore?
There's no non-interactive way to provide credential parameters
NuGet package restore relies on the NuGet.exe commandline tool by using the install command. The commandline will either prompt you for credentials (which isn't suitable for automated build scenarios), or will look for credentials in nuget.config file in %AppData%\NuGet\nuget.config
(if you use the Non-Interactive option).
The latter looks like what you need in automated build scenarios, but requires you to store feed credentials on the machine, for the user account that will perform the build. This can become cumbersome if you have a multitude of solutions using this feature.
Hierarchical NuGet.config doesn't take credentials into account (yet!)
Edit: As of v2.2 released on Dec 12, it is possible to use hierarchical config files for this. Check my follow-up post on this matter.
The latest version of NuGet has support for hierarchical nuget.config files, which is an attempt to overcome the need to store everything on the machine. It allows you to have a solution-level NuGet configuration which should be taken into account during package restore.
This means that feed URL and credentials could be stored next to your solution instead of being pre-configured in the user profile. However, credentials aren't picked up (yet), and there's no easy way to store them (encrypted) into any nuget.config file other than the one in your roaming user profile (explained in the next section of this post).
This is a known issue which seems to be fixed in vNext of NuGet. Check this Codeplex issue for more details. Not sure though whether this will be facilitated without having to copy-paste those encrypted credentials from one config to another.
You can store feed credentials in your user-profile NuGet.config
That's likely to be the easiest approach: as you register the package source URL, you might want to save the required credentials as well. This is however not exposed in the Visual Studio NuGet Package Manager extension, so you'll have to use the NuGet.exe commandline tool, which has a handy but fairly unknown config command (anyone using a corporate proxy?) and sources command. The following gist illustrates a few of these options that should help you configure your secured feed, including credentials.
Leave a Comment