NuGet
All the NuGet Metadata Fields You Should Ignore
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 nuget.org) 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.
| Field | Input | Why |
| Package ID | Use company name | To be unique across organizations and possible expansions. Start with the company name and standardize with division. |
| Package Version | Use SemVer w/Prerelease labels | Our “Best Versioning Practices” goes into more detail, but in a nutshell: SemVer using the Prerelease tag is a must. |
| Author | Use company name | Set to one author (like company name or team name) to keep a standard. |
| Description | Use internal wiki | Use 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 |
| Copyright | Not needed, since it’s a private Internal NuGet package |
| Licensing | Not needed, since it’s a private Internal NuGet package |
| Project URL | Redundant since Description already links to the internal wiki |
| Tags | Complicates searching and is difficult to maintain consistently |
| Release Notes | Redundant since Description already links to the internal wiki |
| Title | Redundant to Project ID |
| Read Me | Redundant to Description and internal wiki |
| Summary | Redundant 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.
