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.
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.
Let’s have a look at how to wire up the NuGet installer.
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!
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:
- It supports solution-wide packages OOB. No special care needed as I discussed earlier in this post.
- An extra tab is added to your build output that lists all the packages. That’s gives you a great overview I think!
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.