Making use of TeamCity’s NuGet capabilities: Part 2

This is the second part of my explorations into TeamCity’s NuGet capabilities. In the first part of the series we talked about packaging and publishing.
I briefly mentioned that TeamCity also has the ability to install packages and that it probably required a post of its own. This is that post.
Enjoy!

Installing Packages

When you add nuget packages to a project (or solution-wide) they are automatically downloaded to a folder called packages that is created at your solution root. The packages and their versions are stored in packages.config files at different locations.
You can later make use of these packages.config files when you don’t want to check-in your packages to version control but instead download them (or the missing ones) at compile/build time. This is called package restore.

TeamCity has the same abilities via the NuGet: installer runner. That runner can accomplish the same…and a bit more as we’ll see shortly.

NuGet: installer

Let’s have a look at how to wire up the NuGet installer.

image

Important! This build step has to be first (or at least before build) in the build step pipeline.

The runner itself is pretty self-explanatory but I’ll mention a few highlights.

Package Sources –

OOB (if you leave it blank) it uses nuget.org but as you can see I’ve chosen to use two sources; nuget.org and the TeamCity internal publish feed (%teamcity.nuget.feed.server%).
This is because since I’m using TeamCity to package and publish a couple of my own nuget packages I might want to test these before I publish them. That means that the version might not be publically available via nuget.org but it will be via the TeamCity feed. This would be much harder via “normal” package restore to accomplish!

image

Then you’ll just give TeamCity the path to your solution file and go hunting!

A few words of caution –

You have the option to exclude the version from the folder names (1). This is not so great though!
Since TeamCity will restore packages without versions the “normal” package restore process (via MSBuild) will not pick up that you have the packages downloaded already and thus the result is that the packages will be downloaded twice.
Lesson: do not exclude the versions!

A word on updates (2). I haven’t been able to get that working satisfactory. And anyway…you’d probably want to handle updates from Visual Studio anyway…right!?

The extra benefit

I promised you that TeamCity has some extras to offer apart from just MSBuild package restore.
There’s actually two things:

  1. It supports solution-wide packages OOB. No special care needed as I discussed earlier in this post.
  2. An extra tab is added to your build output that lists all the packages. That’s gives you a great overview I think!
    image

Summary

You’ve now seen how easy and beneficial it can be to use the TeamCity variant of package restore. Does this mean that you shouldn’t use package restore in Visual Studio then?
Of course not. You should use them both. Package restore is great when a co-worker pulls you changes and you have added a package that he/she is missing. You can however get much more out of the experience by wiring up TeamCity to do the same.

Advertisements

, , ,

  1. #1 by Jesse W on June 24, 2013 - 20:17

    Thanks so much Johan for this. I’m having the issue that TC is updating my packages ok, but it’s not getting the .js and .css files into my web application. So it appears you still have to check in all your Content and Script folders, as well as themes and maybe even others. I’m not seeing this discussed much elsewhere so I’m wondering what I am doing wrong. Package restore is enabled definitely but unless those files are checked in the build complains because it’s not finding the files when it goes to deploy the web app (its going through the project assets).

    • #2 by Johan Leino on June 24, 2013 - 22:03

      Yeah, I think package restore generally doesn’t support those kind of content files + others like C#. You have to check them in yes…
      Thanx…

  2. #3 by David H on June 27, 2013 - 23:10

    This is a great article and is exactly what I was searching for. One question though, how do I modify the NuGet build step so I can change the output folder to something besides a ‘packages’ folder next to the solution? I’m sharing several projects in different solutions so I’m placing all of my packages in a common folder that all solutions reference in the solution’s NuGet.config

    • #4 by Johan Leino on June 30, 2013 - 21:06

      At the moment you can’t, since the nuget installer doesn’t have any options you can send to nuget.exe
      However, you can do it with a separate console runner…kind of what I’m doing here

      UPDATE:
      You can actually change the output folder by adding this to the nuget.config file (usually in the .nuget folder).
      <config>
      <add key=”repositorypath” value=”c:\nuget-packages” />
      </config>

  1. Making use of TeamCity’s NuGet capabilities | Johan Leino
  2. Using TeamCity to enable NuGet package restore for solution-level packages | Johan Leino

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: