NuGet (.NET) Packages and Feeds in Proget

NuGet is the package manager for .NET and a NuGet feed allows client tools like Visual Studio to consume and publish NuGet and symbol packages.

You can also use a NuGet Feed as a proxy for NuGet.org, both to block improper licenses and security vulnerabilities, and to cache packages in case the Internet or NuGet.org goes down.

Integrating NuGet Client Tools

After creating a NuGet feed in ProGet, you can integrate it with NuGet client tools by using the Feed Endpoint URL displayed on the feed overview page:

https://«proget-server»/nuget/«feed-name»/v3/index.json

To use this URL in Visual Studio, navigate to "Tools" > "NuGet Package Manager" > "Package Manager Settings". Then click the green + in the top right of the window, and then name the new package source and paste in your URL:

You can also use the NuGet CLI to add a source:

$ dotnet nuget add source --name "Internal NuGet" https://proget.corp.local/nuget/internal-nuget

Once you've added the NuGet feed as a source, you'll be able to install and upgrade NuGet packages.

Authenticating to NuGet Feeds

By default, NuGet feeds in ProGet do not need to be authenticated to when consuming packages. However, if your feed requires authentication to view and download packages, then you'll need to configure an authenticated source when adding the feed.

When an authenticated feed is added to Visual Studio, you'll be prompted for a username and password. You can enter api for the username and your api key as the password:

Or, you can use the --username and --password arguments in the NuGet CLI:

$ dotnet nuget add source --name "Internal NuGet" --username api --password abcdef12345 https://proget.corp.local/nuget/internal-nuget

See the NuGet CLI sources command to learn more.

Authentication for Publishing Packages

If you use the NuGet CLI to push packages to ProGet, you'll need to also specify an --api-Key argument.

You can also add an API key to a source using the setApiKey command:

$ dotnet nuget setApiKey «api-key» -Source «feed-url»

The NuGet CLI only uses this setting for pushing packages; it will be ignored when viewing/downloading packages, which means you'll also need to add an authenticated source.

Creating and Publishing NuGet Packages

The NuGet package format is well-documented, and you can create packages in a number of ways, including directly from Visual Studio or using using the NuGet CLI.

However, many users find it easiest to publish packages using pgutil. This requires some minor configuration before use, but allows you to more easily specify different feeds.

For example, to upload the package My.Package.1.0.0.nupkg stored at bin\publish to your internal-nuget feed you would enter:

$ pgutil packages upload --feed=internal-nuget --input-file=bin\publish\My.Package.1.0.0.nupkg

Your package will then be uploaded to the internal-nuget feed. To learn more about creating and publishing packages, see HOWTO: Publish NuGet Packages to a Private Repository in ProGet.

Repackaging NuGet Packages

Repackaging lets you create production-ready packages from tested and verified pre-release versions. These "repackaged" packages have identical content, and ProGet maintains an audit trail within the package to track the original versions, who performed the operation, and when.

ProGet supports NuGet repackaging natively. The easiest way to do this is to use the packages repackage command in pgutil. For example, if repackaging version 1.2.3-beta1 of the package MyPackage to version 1.2.3, in the feed internal-nuget you would enter:

$ pgutil packages repackage --feed=internal-nuget --package=MyPackage --version=1.2.3-beta1 --new-version=1.2.3

Symbols and Source Packages

A NuGet feed in ProGet may be configured as a Symbol/Source server compatible with debuggers such as Visual Studio and WinDbg. This will allow you to "step through" code in your NuGet package as if it were in the project.

Configuring this is a bit more involved than simply enabling that feature on your feed, and requires creating special NuGet symbol packages and then configuring Visual Studio to use those packages. See Symbols and Source Code in ProGet to learn more.

Vulnerability Integration

Beginning in ProGet 2023.5, we have added support to show vulnerability information directly in Visual Studio and the NuGet CLI. You will see the severity of your vulnerability along with a link to see the vulnerability details in ProGet.

When selecting a package version with a vulnerability in Visual Studio, you will see the severity with a clickable link to the vulnerability in ProGet.

When running dotnet list package --vulnerable in the NuGet CLI, you will see a list of vulnerable packages with their severity and a link to the vulnerability in ProGet.

Managing Package Deprecation, Deletion, and Unlisting

ProGet will show deprecation information directly in Visual Studio and the NuGet CLI. You will see if a specific version of the package was deprecated along with the specified reason. This works for both packages that come from a NuGet connector and packages that were deprecated using the ProGet UI.

When selecting a package version that has been deprecated in Visual Studio, you will see a warning that the package has been deprecated. If the package has been installed in your project, you will also see a shield in the package list.

When running dotnet list package --deprecated in the NuGet CLI, you will see a list of deprecated packages installed in your project along with the deprecation reason.

Visual Studio and the NuGet CLI heavily caches this information and may take time to show this information after a package has been marked as deprecated. Due to this caching, parts of Visual Studio (version drop-down, version details, and package list) may show the deprecation information at different times.

To force the NuGet CLI to update its deprecated packages, you will need to first clear the NuGet HTTP Cache using the command:

`dotnet nuget locals http-cache --clear`

Then the next time you run dotnet list package --deprecated, the deprecation information will show immediately.

To force Visual Studio to update its deprecated packages, you will need to navigate to "Tools" > "Options" > "NuGet Package Manager" > "General" and then click "Clear All NuGet Storage". This will clear the entire NuGet cache (including cached packages) from the machine and then the deprecated information will show immediately.

In addition to marking packages as deprecated, ProGet allows you to unlist or delete packages from your feed:

Unlisting Packages

Unlisted packages will no longer appear in most search results or Visual Studio. However, these packages can still be installed if the exact version number is specified, making it a useful option for deprecated or outdated packages you want to limit to advanced users.

To unlist a package you can use the packages status unlisted command in pgutil. For example, if unlisting version 1.2.3 of the package MyPackage from the feed internal-nuget you would enter:

$ pgutil packages status unlisted  --feed=internal-nuget --package=MyPackage --version=1.2.3 --state=listed

Deleting Packages

Deleting a package will make it permanently unavailable for installation and reference, impacting all users relying on that package version. Before deletion, make sure no active projects depend on it, as removal could lead to build or runtime failures.

To delete a package you can use the packages delete command in pgutil. For example, if deleting version 1.2.3 of the package MyPackage from the feed internal-nuget you would enter:

$ pgutil packages delete --feed=internal-nuget --package=MyPackage --version=1.2.3

Troubleshooting

My CI build can’t find a recently published package

The NuGet client maintains a 30-minute HTTP cache for package restore responses. In situations where you deploy more than one new version of a package within 30 minutes, and produce a CI build referencing each of those packages within that 30-minute window, your build will likely fail with a package not found error. This is a known issue in NuGet, and can be worked around by deleting the http cache on your build server prior to restoring packages:

$ dotnet nuget locals http-cache --clear

See NuGet GitHub Issue 3116 for more information about this error.