Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to Create and Publish NuGet Packages Using .NET Core CLI

DZone's Guide to

How to Create and Publish NuGet Packages Using .NET Core CLI

In this post, we take a look at how to create NuGet packages using CLI commands, and then how to publish these packages with CLI commands.

· Web Dev Zone ·
Free Resource

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

In my previous post on CLI tools, I explained how to create, restore, clean, build, and run a .NET Core application using the latest CLI commands. You can find that post here.

In this post, we will learn how to create and publish NuGet packages using CLI commands.

What Is a NuGet Package?

The official NuGet documentation sums up the importance of NuGet as follows:

An essential tool for any modern development platform is a mechanism through which developers can create, share, and consume useful code. Often, such code is bundled into "packages" that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages.

For .NET (including .NET Core), the Microsoft-supported mechanism for sharing code is NuGet, which defines how packages for .NET are created, hosted, and consumed, and provides the tools for each of those roles.

Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number.

As you can see in above image, we can build/pack a whole project into a NuGet Package and we can then publish this NuGet package to either nuget.org or any other private host. Once published, we can use this package within .NET projects or we can even install/deploy this package to any server.

As a developer, you should be familiar with NuGet packages because they are a really important part of .NET projects.

For this post, we will use the same application we created in Part I of this series.

Nuspec Files

Nuspec files are very important for NuGet packages.

NuGet packages require manifests which describe the package dependencies and the content, this manifest is  the .nuspec file.

As per Microsoft's docs:

A .nuspec file is an XML manifest that contains package metadata. This manifest is used both to build the package and to provide information to consumers. The manifest is always included in a package.

It is a good practice to create a Nuspec file in which you mention all the dependencies and the details of the package, otherwise, the system will generate the Nuspec file when we run the pack command.

If you do not wish to create a Nuspec file, it is good to at least to add some details in your .csproj file, which will be used to generate the Nuspec file. Add the below properties in the .csproj file:

<PackageId>SampleCliApp</PackageId>
<Version>1.0.0</Version>
<Authors>Neel</Authors>
<Company>CompanyX</Company>

You can add the same details from Visual Studio 2017. For this, right-click on project -> Click Properties -> Open the Package tab and fill in the details:

More details on Nuspec can be found in the Microsoft docs.

Create NuGet Packages

Web applications are not packable by default. To change this, modify your .csproj file to include this property:

<IsPackable>true</IsPackable>

Once the property is added, run the below command to create a NuGet package:

dotnet pack

A NuGet package would be created at the location, bin\debug\.

Check here if you want to see different options for working with the dotnet pack command.

Publish Package

As we have just created the NuGet package, we need some space to store our packages.

Nuget.org provides a space where you can store your NuGet packages, but they are public so other developers can also see your packages. If you do not wish to use nuget.org, there are other options like:

More details on NuGet hosting packages can be found here.

For this post, we will publish the package to nuget.org

Publish to Nuget.org

We can publish our packages to nuget.org once we have the API keys. Let's go step-by-step to get the key and then to publish the packages using that key.

To publish the packages to nuget.org, we need to create an account.

Once your account is created, click on your account name -> Click on API keys:

Create a new API key:Once the keys are created, note down the key:

Important Note: You can not copy this key later on because you will be required to create new keys \ the second time, so save the keys at the time of creation.

Once we have the key, we can use the dotnet nuget push command, as demonstrated below:

dotnet nuget push SampleCliApp.1.0.0.nupkg -k yourApiKey -s https://api.nuget.org/v3/index.json

Here -k stands for API keys and -s stands for source; in our case, the source is nuget.org so we provided the path correctly.

As you can see in the logs, the packages are pushed to nuget.org.

Let us go back to nuget.org to check our packages:

You can Update/Delete the packages.

Have a look here if you want to see different options for using dotnet nuget push.

Browsing Our NuGet Package

Once we have published our package to nuget.org, we should be able to browse this package from Visual Studio.

Open up Visual Studio -> Manage NuGet package -> Search for your package. In my case, I searched for SampleCliApp:

The package is available, as you can see above!

In future posts, I will explain how to use CLI commands to work with CI (Continuous integration).

Hope this helps!

Deploying code to production can be filled with uncertainty. Reduce the risks, and deploy earlier and more often. Download this free guide to learn more. Brought to you in partnership with Rollbar.

Topics:
web dev ,nuget ,.net core cli ,.net core

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}