All the NuGet Metadata Fields You Should Ignore


Crista Perlton

Crista Perlton


Why You Should Create a Package Approval Workflow for  27th September, 2023

Do I really need to leave .NET Framework for .NET 8? 13th September, 2023


All the NuGet Metadata Fields You Should Ignore

Posted on .

There are over 25 metadata properties that can be filled in a NuGet .nuspec file. And those choices are permanent – once you publish a package, you can’t edit or change the package.

Deciding what to input and how to standardize each can be a lot of extra, unnecessary work. But fortunately, if you’re creating private/internal packages, you can ignore all but five metadata fields in a NuGet package with no consequences.

At Inedo, we’re all about best practices: from automated deployment in Jenkins, to organizing PowerShell modules, to versioning NuGet packages. We focus on best practices because we want to encourage optimization in our DevOps community; cutting out fat to get to the meat.

Like unnecessary metadata in NuGet packages.

Foundationally, the metadata helps with the discoverability, usability, and (if publishing in places like trustworthiness of a package. Operating in an organization, however, where packages remain internal, it’s best to keep the metadata simple. Working with first-party packages means you don’t have to “sell” people on your package and win more downloads.

This article is a quick explainer of which metadata fields are necessary for internal projects, and which fields can be ignored.

Required Metadata Fields

These fields are required to make the package – e.g. you can’t publish without them.

Package IDUse company nameTo be unique across organizations and possible expansions. Start with the company name and standardize with division.
Package VersionUse SemVer w/Prerelease labelsOur “Best Versioning Practices” goes into more detail, but in a nutshell: SemVer using the Prerelease tag is a must.
AuthorUse company nameSet to one author (like company name or team name) to keep a standard.
DescriptionUse internal wikiUse to link to the company Wiki page & maintain the most up-to-date information.

Though not required, we recommend using:

  • Icon; this can be a quick visual cue for differentiating a NuGet package from others in a private repository on Visual Studio
  • Repository; the repositoryURL and RepositoryType fields will let you Debug NuGet Packages and Libraries 

Metadata Fields to Avoid

These are the fields you don’t need to fill in and will see no negative impact from leaving blank.

Ignorable Field Why
CopyrightNot needed, since it’s a private Internal NuGet package
LicensingNot needed, since it’s a private Internal NuGet package
Project URLRedundant since Description already links to the internal wiki
TagsComplicates searching and is difficult to maintain consistently
Release NotesRedundant since Description already links to the internal wiki
Title Redundant to Project ID
Read MeRedundant to Description and internal wiki
SummaryRedundant to Description and internal wiki

Metadata Best Practices

Cutting unnecessary metadata will help standardize NuGet packages in your team and within your organization. It’s important to keep with set standards since packages are immutable and cannot be renamed, changed, or edited.

Others steps you can take to help promote NuGet standards to your team are encouraging best versioning practices or setting up filters to avoid unwanted NuGet packages.

Crista Perlton

Crista Perlton