TeamCity Building NuGet Packages

NuGet and TeamCity

Opening and building large Visual Studio solutions is a pain. A good way to put less stress on your rig is to start moving rarely changing parts of your code into NuGet packages. NuGet has been around already since 2010, tools are mature and battletested. NuGetizing some of your system makes parts of your code always prebuilt and tested (you are using tests right?). Offloading some of the building and tests will make your overall CI (Continuous Integration) process faster as well.

There are several steps involved when creating a NuGet packages, which involve:

  • Making a .nuspec manifest file (which has the metadata)
  • Building, testing and incrementing the build number
  • Creating a .nupkg package file (essentially a zip file)
  • Publishing the newly created package

You can perform all the aforementioned activities by hand, write a bat script or use a build server (like TeamCity). In this article, we’ll take the latter approach. Setting up a CI pipeline in TeamCity is super easy.

To begin with, create a new project, configure your version control settings and start setting up build steps.

TeamCity Build number

The simplest way to change the build number is to increment the minor version (check Semantic Versioning). Every build will then increment the counter, which is not an ideal solution but will do for that example.

Build number now in place, we can use it in our assembly and NuGet package version. Before setting up the CI pipeline, configure the AssemblyInfo patcher, found under the Build Features:

TeamCity AssemblyInfo patcher

This will change the values in the Properties/AssemblyInfo.cs file.

We can now set up our build pipeline, on the example of fictitious logging library Foo.Common.Logging. The CI process consists of 6 steps:

CI pipeline for NuGet

1. Restore all the NuGet packages used in the solution.

2. Build all the projects in the solution

3. Run unit tests with coverage report. You can set the pipeline to fail if test coverage drops under threshold.

4. ReSharper runs various inspection on your code, read more from their docs.

5. When all the tests and inspections are green, we can then pack the project into a NuGet package.

6. Publishes the NuGet package. Here we used a simple file share, but alternatively TeamCity can host the package feed or a real server.

You can start the pipeline either manually or configure a VCS trigger under Build settings > triggers.

TeamCity NuGet Build

Now sit back and enjoy your new automated NuGet packaging process!