TeamCity is a product with many strengths. One of them is the built-in support for working with all aspects of NuGet. This post is a summary of my experiences in that area.
Let’s start with setting up NuGet on our TeamCity server.
From the admin view, locate the integrations section. And from there, go into the NuGet settings.
First, start off by enabling the TeamCity server as a NuGet server. This is of course optional but I strongly recommend it.
You can now see that we get two feed urls, these (or one of them at least) will be handy later on.
Depending on your company’s policy and such you may or may not have the ability to enable guest login but I strongly recommend that.
Next up we’ll make sure than we can use some other aspects of the NuGet integration by setting up nuget.exe:
You can either fetch one or more versions of nuget.exe from nuget.org or upload a version from your machine. If you’ve got more than one version is entirely based on your setup of course.
Consuming the TeamCity NuGet feed
To be able to consume the packages we let TeamCity create, whether they are internal ones or just for testing them before publishing to nuget.org, we need to add one of the feed urls that we saw earlier.
Go into Package Manager Settings from Visual Studio.
…and add give the new feed a friendly name and then the url from earlier. (I’ve got the public one).
And that’s it…we’re ready to start rockin’
Creating a package
We can now use TeamCity’s ability to create (and automatically host) nuget packages.
You need to have the .nuspec file in source control and from that file it’s all just a matter of clicks.
Create a new configuration and let’s begin…
Letting TeamCity set the version (optional)
You can of course keep the version in the .nuspec file or have MSBuild set it through a project file (then you’ll need to a MSBuild build step before the actual packing step though).
I’m on the other hand letting TeamCity set the version and thus controlling it from with general settings tab of the build configuration.
The upside to this approach is that we’ll clearly see the version on the dashboard page.
The downside is that we’ll have to remember to change it when we need a new major, minor, or build number. The revision is handled by TC.
Configuring the NuGet:Pack runner
Create a new NuGet: Pack build runner build step.
Pretty self-explanatory but some highlights are:
- if you’ve got multiple versions of nuget.exe setup, choose the correct one.
- add the .nuspec files you wish to package (this all presumes you’ve setup your version control setting already and then you’ll get that nice dropdown of your checkout folder).
- if you have the version number coming from TeamCity, set the version to %build.number% (or some other parameter if you’ve got that) or else leave it blank.
- you’ll have to add an output directory for the generated packages and you have the option to publish the packages as build artifacts (which will be very handy)
Now if you’ve got all this down all you have to do is “push the button” and…et voilà
The .nupkg file ended up as a build artifact + TeamCity published it to the internal feed which enables us to pick it up from Visual Studio (Package Manager).
Now we can consume it directly within the company (if it was only internal) or test it before we publish it to the world.
Publish a package
If we where only building internal NuGet packages that would be it but you might very well wish to publish them to nuget.org, right?!
Let’s start by creating a new build configuration for handling that…
I’ll start by “linking” my publish build configuration to the package build configuration by downloading the created .nupkg file from the artifacts of that build (I’m using the latest successful build).
I’m also cleaning my destination paths because I’m using a wildcard for downloading the .nupkg file and I don’t want to end up with multiple packages in the checkout directory.
I want the same build number on my publish build as on my package build (on the dashboard). Therefore I’m using the build number from package (bt8) as my build number on the publish configuration.
I’ve discussed this approach in greater detail previously though.
Configure the NuGet: Publish build runner
Lastly, all we need to create a NuGet: Publish build runner:
Nothing much to say other than nuget.org is the default source and the packages to upload will be relative from you checkout folder. Since I’m cleaning the folder as part of the artifact resolving I trust there will be only one package there for me to publish.
Push the button and your nuget package will be published to nuget.org!!
OK, that’s it. I hope this tutorial has given you some input into TeamCity’s capabilities when it comes to NuGet.
The last thing that we haven’t touched upon is installing packages which is also a capability of TeamCity. However, that will probably require a post of its own so I’ll get back to you on that…OK.