Lately I’ve been playing with the new NuGet integration that is baked into TeamCity 7.X. It works great, and has almost all of the features that I was looking for. However, there still needs to be some thought put toward how you should configure your project for publishing packages. For example, do you want new packages generated and published every time a developer commits a change, or only on demand when a candidate build is vetted as “stable”? TeamCity gives you all of the Lego blocks you need to get the setup you want, but you still have to arrange those blocks in the way that makes sense for you and your team. In this post I’m going to describe the setup that I recommend for publishing NuGet packages with TeamCity.
I am a big fan of using NuGet for managing dependencies between different .NET projects. Lately I’ve been focusing on using it for managing internal dependencies within an organization. Most organizations end up with some shared code that is used across multiple applications: logging, security, database access, common domain models, etc. A great way to handle this shared code is to publish it as an internal NuGet package, and then point all of the consuming applications at that package. Additionally, TeamCity can be used to ensure that new packages are created automatically whenever the shared code is updated, and those packages are instantly made available to consumers.
This setup works great, but it can be confusing as there are a lot of moving parts. One of the most confusing parts is the amount of different version / build numbers you end up juggling. This post explains how to configure everything so that the same version number is used in every piece across the entire process.
Thanks to those few that attended my talk on Saturday at the 5th Hartford Code Camp. Nuget is a really powerful tool, and I’m glad this talk gave me the opportunity to really dig in and learn it. If you want the slides or any of the code samples, you can download everything from this link: