Managing Published Packages

This section documents MSBuild 18.9, the .NET SDK 10.0.402 (with its dotnet CLI) and NuGet 7.9, as published in the MSBuild, .NET and NuGet documentation on learn.microsoft.com, which is the reference these pages are written and verified against. Material about .NET 11 / NuGet 8.0 is still in preview and is always flagged as such — never presented as baseline.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The C# Reference bibliography lists the reference material consulted while preparing these pages.

Publishing is not the end of a package’s life. A version may turn out broken or vulnerable, a package may be replaced by a better one, an owner may leave. nuget.org’s rule shapes every answer: published versions are never deleted, because builds that restore them would break. What owners can do is hide, mark and redirect. This page covers those tools; the unlist round trip was run on the local BaGetter feed with .NET SDK 10.0.402 (NuGet 7.9.0), and the nuget.org steps are "not run here".

Unlisting instead of deleting

nuget.org does not support deleting packages; only the NuGet team removes packages, in exceptional cases (copyright infringement, harmful content) or for prohibited use — malware, packages designed to harm, licence violations, illegal content, name squatting (packages with no productive content), or Terms of Use violations. Owners use Report abuse or Contact support on the package page.

Unlisting hides a version from search and the package page, but it still restores when asked for by exact version, and a floating version (1.0.0-*) or range can still resolve to it if it is the best match. It is the tool for "stop new users from picking this", not for "make it disappear".

On nuget.org, unlist on Manage packages > Listing, or from the command line — dotnet nuget delete unlists on nuget.org. On BaGetter, configured as here, it unlisted as well:

dotnet nuget delete Ledgerline 1.0.1 -s http://localhost:5555/v3/index.json -k "$BAGETTER_API_KEY" --non-interactive
warn : Deleting Ledgerline 1.0.1 from the 'http://localhost:5555/api/v2/package'.
  DELETE http://localhost:5555/api/v2/package/Ledgerline/1.0.1
  NoContent http://localhost:5555/api/v2/package/Ledgerline/1.0.1 69ms
Ledgerline 1.0.1 was deleted successfully.

Despite "deleted", the feed afterwards showed exactly the unlisting behaviour:

flat container versions:  {"versions":["1.0.0","1.0.1"]}
search:                   [('Ledgerline', '1.0.0', ['1.0.0'])]
registration listed:      [('1.0.0', True), ('1.0.1', False)]

and Ledgerline.Report, which references 1.0.1 exactly, still restored with --no-http-cache --force. Without --non-interactive the command asks for confirmation.

Source: Deleting packages: Exceptions, Prohibited use, Unlisting a package, FAQ: Can I delete a package, dotnet nuget delete.

Deprecating

Deprecation keeps a version listed but tells everyone who has it installed that they should move: Manage packages > Deprecation, select versions (or all), and a reason:

  • Legacy — no longer maintained;

  • Has critical bugs — for a specific version;

  • Other;

plus an optional alternate package (and version) and a custom message — the message appears only on nuget.org, not in clients. Consumers see:

  • Visual Studio (2019 16.3+): a warning on the Installed tab with the reason and the alternative.

  • dotnet list package --deprecated (.NET Core 3.0 SDK+), with the reason and alternative per package. It queries all configured sources, ignoring package source mapping, so internal package IDs reach public sources.

Deprecating and unlisting are independent; a broken version usually gets both.

A deprecated package with many downloads can outrank its replacement in search. Popularity transfer moves the search popularity (not the download counts) from the deprecated package to the new one: e-mail account@nuget.org with the deprecated package and the stable packages to receive it; both must have exactly the same owners.

Source: Deprecating packages: Workflow, Client experience, Transfer popularity, Popularity transfer application.

Vulnerable versions

When a version of your package has a vulnerability, the security guidance for authors is to deprecate and unlist it and to report it to the GitHub Advisory Database. nuget.org’s vulnerability data comes from that database; once an advisory names the package and version range, every consumer running NuGetAudit gets NU1901--NU1904 on restore, by severity, and dotnet package list --vulnerable lists it (Auditing Packages for Vulnerabilities). Publish the fixed version first, so the advisory can name it as the patched version.

Source: Security best practices: Deprecating and unlisting a vulnerable package.

Owners, sponsorship and disputes

  • Ownership belongs to whoever published the package (the uploader or the API key’s owner), never to the .nuspec authors. Owners have full rights, including adding and removing owners: Manage package > Owners. To transfer a package, add the new owner (who must accept the invitation) and then remove the old one; for an organization see Accounts and Organizations.

  • Sponsorship — owners can add sponsorship links (GitHub Sponsors, Patreon, Open Collective, Ko-fi, Tidelift, Liberapay) under Manage Packages > Sponsorship Links; they appear behind a Sponsor button on the package page.

  • Disputes over a name — contact the owners through Contact Owners, copy support@nuget.org, and after at most 30 days without a resolution notify support again; the nuget.org team then mediates.

Source: Manage package owners, Package sponsorship, Dispute resolution.

Common mistakes

  • Expecting unlisting to stop restores — exact versions still restore; deprecate too, and publish a fix.

  • "Deleting" with dotnet nuget delete — on nuget.org (and on BaGetter as configured here) it unlists.

  • Deprecating without an alternative — consumers learn what not to use, but not what to use.

  • Removing yourself as owner before the new owner accepted — the package can end up without the intended owner.

  • Silently fixing a vulnerability — without an advisory, NuGetAudit users never learn they should upgrade.

References