Day #19 Creating And Publishing a Nuget Package

Osman Sokuoğlu

3 min read

·

Aug 21, 2026

--

Listen

Share

Press enter or click to view image in full size

1. Configure the Project

In Visual Studio:
Right-click the project → Properties → Package

Configure the required package information:

• Package name
• Version
• Description
• Author
• Company
• Repository information

Note: If the Package section is not available, make sure the project is a .NET Class Library.

You can also define the package information directly in the .csproj file:

<PropertyGroup>
    <PackageId>MyLibrary</PackageId>
    <Version>1.0.0</Version>
    <Authors>MyCompany</Authors>
    <Description>My reusable .NET library.</Description>
</PropertyGroup>

2. Review the Project Before Packaging

Before creating the package:

• Remove unnecessary dependencies.
• Keep only the required NuGet packages.
• Make only the intended APIs public.
• Keep internal implementation classes internal.
• Review all ProjectReference entries.

For example:

<ItemGroup>
    <ProjectReference Include="C:\Projects\Aware\Aware.csproj" />
</ItemGroup>

Important: Be careful with local ProjectReference dependencies. If the referenced project is not included or distributed with your package, consumers may not be able to resolve the dependency.

For reusable libraries, consider publishing shared projects as separate NuGet packages instead of relying on local project references.

3. Create the NuGet Package

Open a terminal in the directory containing the .csproj file and run:

dotnet pack --configuration Release

The generated package will normally be available under:

bin\Release\

For example:

bin\Release\
└── MyLibrary.1.0.0.nupkg

Version Your Packages

Every package release should have a clear version.

For example:

1.0.0  → Initial release
1.0.1  → Bug fix
1.1.0  → New backward-compatible functionality
2.0.0  → Breaking change

Keep the Public API Small

Everything marked as public can become part of your package's external contract. Only expose what consumers actually need.

4. Publish the Package to NuGet.org

Once the .nupkg file is ready, you can publish it to NuGet.org. There are two common ways to publish a package to NuGet.org.

Option 1: Upload from NuGet.org

For a manual release, you can upload the .nupkg file directly through the NuGet.org web interface.

1. Sign in to NuGet.org.
2. Go to the package upload page.
3. Select your .nupkg file.
4. Review the package information.
5. Submit the package.

This is convenient when publishing a package manually.

Option 2: Publish Using the .NET CLI

First, sign in to NuGet.org and go to API Keys. Create a new API key with the Push permission and copy the generated key. Then open a terminal in the folder containing your .nupkg file and run:

For CLI-based publishing or CI/CD pipelines, use:

dotnet nuget push MyLibrary.1.0.0.nupkg \
    --api-key YOUR_API_KEY \
    --source https://api.nuget.org/v3/index.json

The .NET CLI requires authentication when pushing packages to NuGet.org.

If the upload is successful, NuGet.org will process the package and make it available on the package page.

Important: Packages published to NuGet.org are publicly visible. Also, treat your API key like a password. Never commit it to source control or include it directly in your code.

5. Preparing a New Version

When releasing a new version, first update the package version in the .csproj or Visual Studio's Package settings.

For example:

<PropertyGroup>
    <Version>1.1.0</Version>
</PropertyGroup>

Then review your changes, update the Change Notes, build the project, and create the new package:

dotnet pack --configuration Release

Before publishing, it is a good idea to test the new .nupkg in a sample or test project to make sure the package works as expected.

6. Maintain Change Notes

Change Notes should be short and focused on what changed for the package consumer.

A simple format works well:

## 1.1.0 - 2026-08-21

### Added
- Added support for XYZ.### Changed
- Updated ABC behavior.### Fixed
- Fixed an issue with XYZ validation.

For a smaller release, you don’t need to include every section:

## 1.0.1 - 2026-08-21

### Fixed
- Fixed an issue where XYZ could return an incorrect result.

Important: Change Notes should describe the impact of the release, not every individual code change or commit.

For example, this is useful:

- Added support for multiple authentication providers.

Instead of:

- Refactored AuthenticationService.
- Changed method X.
- Added class Y.
- Updated variable Z.