How to autogenerate a nuget package and specify the version?

Kat Lim Ruiz
2 min readMar 24, 2020

When you have a library that you want to publish as a nuget package, you normally have to call nuget pack and nuget push .

And if you use a pipeline, like in Azure Pipelines, you would call this task to pack the library.

- task: NuGetCommand@2
displayName: 'nuget pack'
inputs:
command: pack
packagesToPack: MyLib.nuspec
packDestination: /out
versioningScheme: # off, byPrereleaseNumber, byEnvVar, byBuildNumber

And this task to publish it.

- task: NuGetCommand@2
displayName: 'nuget push'
inputs:
command: push
packagesToPush: /out/*.nupkg
nuGetFeedType: # internal, external
publishVstsFeed: # feed url

In .NET Core projects, things can be done a little differently.

You can set the <GeneratePackageOnBuild>true</GeneratePackageOnBuild> property in the csproj file so every build will generate the nupkg file. Or you can enable it in Project Properties/Package/Generate NuGet package on build.

This would generate a nuget package file bin/Release/MyLib.1.0.3.0.nupkg with the corresponding version.

In .NET Core projects, the version is located inside the csproj file (like nodejs does it because the version is in package.json file). So, in order to set the version, you can either:

  1. Set manually in Visual Studio just before committing your changes.
  2. Set automatically in your pipeline.
  3. Or perhaps a combination of both (manually set the major.minor, and let the pipeline set the patch).

In my case, I want to set the version number automatically because these are internal nuget packages (we use Azure Artifacts for this).

When you manually do the nuget pack and publish, the version number can be assigned to the package after the build, but in our case where we want to use GeneratePackageOnBuild=true, then the version has to be set before building the project.

Since the version field is a property inside the csproj file, then you can actually set it from the command line like any other property.

# set the build number
name: $(Year:yyyy).$(Month).$(DayOfMonth).$(BuildID)
...- task: VSBuild@1
inputs:
solution: MyLib.sln
platform: Any CPU
configuration: Release
msbuildArgs: /p:Version=$(Build.BuildNumber)

In my case I use the build number (coming from the name instruction that I normally put at the beginning of the file), but you can set any other value needed.

Happy coding!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Kat Lim Ruiz
Kat Lim Ruiz

Written by Kat Lim Ruiz

Software Engineer, father, technology enthusiast, agilist, INTJ, Developer, Mini-Devops.

Responses (1)

Write a response

Hi Kat Lim, here are some alternatives,
1. NGINX Plus: Native JWT support with ngx_http_auth_jwt_module.
2. OpenResty + lua-resty-jwt: JWT handling via Lua scripting.
3. Third-party modules: Check ngx-http-auth-jwt-module or nginx-auth-jwt.

--