How to Create NuGet Packages with nuget.exe (Assembly, .nuspec, and .csproj Methods)

Creating a NuGet package is a core skill for .NET and DevOps engineers who need to distribute internal libraries, scripts, or reusable project assets. This guide explains the three packaging approaches shown in the original tutorial, when each one fits best, and the exact commands and manifest structure you need to produce a .nupkg artifact.

Originally published on 2015-11-21; fully revised and updated.

Choose the right packaging method

The original tutorial presents three ways to create packages with nuget.exe. In practice, your starting point (compiled DLL, folder layout, or project file) determines which workflow is fastest.

NuGet packaging workflow

All three methods follow the same high-level flow: generate or prepare a manifest, verify package content, build the package, and then publish to your feed.

flowchart TD
    A[Start packaging] --> B{What do you have?}
    B --> C[Compiled assembly]
    B --> D[Folder layout and files]
    B --> E[Project file]
    C --> F[Generate nuspec from dll]
    D --> G[Generate or edit nuspec]
    E --> H[Generate tokenized nuspec]
    F --> I[Edit metadata and dependencies]
    G --> I
    H --> I
    I --> J[Run nuget pack]
    J --> K[Validate nupkg contents]
    K --> L[Publish to repository]

Method 1: Create a package from an existing assembly

Use this when you already have a compiled assembly and want NuGet to scaffold a .nuspec from assembly metadata.

nuget spec MyAssembly.dll
nuget pack MyAssembly.nuspecCode language: CSS (css)

After generating the .nuspec, update metadata fields (ID, version, description, dependencies) before packing.

Method 2: Create a package from a convention-based directory and nuspec

This method is ideal when the package includes more than assemblies, such as content files, scripts, and build artifacts.

Step 1: Generate the manifest

nuget spec

This creates a .nuspec file you can edit. Example manifest from the original tutorial:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>MyPackageId</id>
    <version>1.0</version>
    <authors>philha</authors>
    <owners>philha</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package description</description>
    <tags>Tag1 Tag2</tags>
    <dependencies>
      <dependency id="SampleDependency" version="1.0" />
    </dependencies>
  </metadata>
</package>Code language: HTML, XML (xml)

Step 2: Lay out package content and build

mkdir lib
mkdir tools
mkdir content
mkdir content\controllers
copy ..\src\SomeController.cs content\controllers
copy ..\src\MyLibrary.dll lib
copy ..\src\SomePowershellScript.ps1 tools
nuget pack YourPackage.nuspecCode language: CSS (css)

Method 3: Create a package from a Visual Studio project

For simple project-based packaging, run commands in the folder containing the .csproj (or .vbproj) file. NuGet creates a tokenized .nuspec and replaces tokens during packing when you pack the project file.

nuget spec
nuget pack MyProject.csprojCode language: CSS (css)

Supported replacement tokens highlighted in the original article:

You can also include additional files through a <files> section in the .nuspec:

<files>
  <file src="..\..\SomeRoot\**\*.*" target="" />
</files>Code language: HTML, XML (xml)

Referenced projects can be included recursively with -IncludeReferencedProjects, and build configuration can be selected with -Prop:

nuget pack A.csproj -IncludeReferencedProjects
nuget pack MyProject.csproj -Prop Configuration=Release

Official references

• https://docs.nuget.org/create/creating-and-publishing-a-package
• https://docs.nuget.org/consume/command-line-reference

Common pitfalls

• Packing the .nuspec instead of the project file when you expect token replacement from project metadata.
• Using a folder layout that does not match NuGet conventions, causing files not to land where consumers expect.
• Forgetting to review dependency versions in the generated .nuspec before publishing.
• Mixing Debug and Release artifacts unintentionally; use -Prop Configuration=Release when needed.
• Assuming package creation and repository hosting are the same step; package creation is separate from publishing to a feed.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.