Publish a package with Visual Studio to Nuget


In this post I will demonstrate how to publish a Net Standard class library as a package to the Nuget server/repository.

I will also touch on versioning, managing and deleting this package.

What is required

*If you have a Microsoft account this should be very easy since Nuget and Visual Studio use the same account.

Let’s get straight into action by creating the net core application

You can either have a Nuget package as a dedicated application for packages or it being a project within an application. For instance if you have a class library containing shared contracts or models within an api application.

We can start by either creating a Blank Solution and then manually adding a class library or choose a Class Library straight away. For the latter the solution is created automatically. However the name of the class library would be the same as the class library itself.

I will do the Blank Solution option and manually add the class library.

Class Library should be of Net Standard, as it provides compatibility with different projects of various Net implementations.

Let’s get our package ready to be published

I think it’s a good time to mention several points in regards to versioning of the nuget packages. A recommended approach is to use SemVer or the full name is Semantic Versioning. It follows the format of Major.Minor.Patch[-Suffix]

  • Major: Breaking changes
  • Minor: New features, but backwards compatible
  • Patch: Backwards compatible bug fixes only
  • -Suffix (optional): a hyphen followed by a string denoting a pre-release version (following the Semantic Versioning or SemVer 1.0 convention).

For example 1.2.3, 1.5.9-prerelease. In general whatever suffix you put the Nuget package manager will put it under prerelease type. This means you would have to tick ‘Include prerelease’ in Visual Studio when searching for nuget packages.

When searching make sure you got the correct source selected. You can check the settings by clicking on cogwheel icon or go to Tools > Options > Nuget Package Manager > Package Sources

Okay if you open properties for the Class Library you created. Right Click >Properties. In there you would be able to see a place where you can set the required version number. It would be under Package option.

Let’s pack it

In the solution explorer of Visual Studio right click on your class library and select Pack.

This should produce a nupkg file in Debug(Release folder on server or in production mode) folder that is inside the bin folder which in its turn is placed in the class library root folder. For example C:\Users\dmitr\source\backend\DgVsNuget\DgLoggers\bin\Debug

This also generates a nuspec file but instead of a bin folder it would be in the obj folder. For example C:\Users\dmitr\source\backend\DgVsNuget\DgLoggers\obj\Debug
This file contains package metadata like id, package version, authors etc. Some details we set when we edited values in class library properties under Package option.

Let’s publish it

Firstly let’s check if we got net core cli installed. For this we need to open Command Prompt and type in ‘dotnet’ command.

Then we need to navigate to the folder where our nupkg file lives. For me it’s C:\Users\dmitr\source\backend\DgVsNuget\DgLoggers\bin\Debug

The complete command should look like this ‘cd C:\Users\dmitr\source\backend\DgVsNuget\DgLoggers\bin\Debug’

Then we need to run the command which would contain the name of your package file, as it is in the bin/Debug or bin/Release folder, the api key that you generate in your account with Nuget and also the source url.

For me the command would look like so ‘dotnet nuget push DgLoggers.1.0.1-prerelease.nupkg –api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 –source’

Api key can be generated on your account at
For Glob Pattern enter star *

For source we put because we use Nuget server. The url is the same format with possible version differences.

Once you assembled the command type it into command prompt/net core cli and hit the enter.

Once it successfully pushes you can view it in your Nuget Account. For a brief moment it would be in Unlisted state. Once Nuget approves it will go into Published state.

I would recommend setting it as Unlisted. This way it’s not searchable. You can still install it with the version you need. For this you need to go to your Nuget Account and select Manage Packages. There you would see Published Packages and option to go to package details. Once you are on the manage page for the current package you can deselect the listed option.

Let’s use this package

Since we set this package as Unlisted we need to use the package manager console and use the install command where you specify the version.

Firstly create a new Asp.Net Core Application as web api.

Once the application is created go to Package Manager Console and type in Install-Package Your-package-name -Version the-version-you-need
For example Install-Package DgLoggers -Version 1.0.1-prerelease

Install-Package DgLoggers -Version 1.0.1-prerelease

You can find the complete command at the Nuget page for your package. The url should be of this format

After that initiate package TextLogger class and call Log method with supplied message in the controller of your choice.

        public IEnumerable<WeatherForecast> Get()
            //here we initiate the package logger
            var pckgLogger = new TextLogger();
            pckgLogger.Log("test logger");

            var rng = new Random();
            return Enumerable.Range(1, 5).Select(index => new WeatherForecast
                Date = DateTime.Now.AddDays(index),
                TemperatureC = rng.Next(-20, 55),
                Summary = Summaries[rng.Next(Summaries.Length)]

When you run the application check the Output window for this message.

Let’s talk about deleting the package

As it’s stated on Microsoft page does not support permanent deletion. There are exceptions but not many. And you have to contact the Nuget team.

Despite that you can unlist the package. Which essentially means it’s still active and can be installed but not searchable. So you have to know that such a package exists and know the versions that are available.

Even though Nuget Cli provides a delete method, what it does is it simply unlists the package. The package has to be active/published.

Just to give you an idea of the process. Let’s go back to and activate/list our package.

The required details we need are the same as for when you publish the package. For this we need to generate the api key at When generating the api key make sure Unlist package scope is ticked.
We also need to include the source as into the delete command.

The complete command should look like so dotnet nuget delete DgLoggers.1.0.1-prerelease.nupkg –api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 –source

dotnet nuget delete DgLoggers 1.0.1-prerelease --api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 --source --non-interactive

Let’s go back to Visual Studio and run it in the Package Manager Console. Alternatively you can use command prompt/net core cli.

So if you go back to your package on it should be set as unlisted.

Let’s talk about updating the package too

As you can imagine the process is the same as when we publish the package. We need to change the version in the Project Options Package section. Then pack it. To note we need to use the newly generated nupkg file name. For instance DgLoggers.1.0.2-beta.nupkg

Then run the command in net core cli/command prompt.

dotnet nuget push DgLoggers.1.0.2-beta.nupkg --api-key qz2jga8pl3dvn2akksyquwcs9ygggg4exypy3bhxy6w6x6 --source

If it’s in status listed at then Nuget Package Manager in Visual Studio would pick up that there is a new version available. Simply update it from there.

If it’s not listed then you need to do it manually by using the command from for your package with a specific version.


Having nuget packages with the code that would be reused is a great way of preventing code duplication.

Possibly you just want to isolate a particular piece of code from the main source code. That works too.

You can think that the code in the package follows the object-oriented principle of abstraction. As long as we know what the package does and what methods are available to use there is no need to know details of package code.

It still depends what you will put in there, might be simply some contracts or models that you want to share between projects. It’s up to you. Hopefully something reasonably sized.

You can find a code for the package here and the consumer application here.