Hosting NuGet in TeamCity and consume it in Visual Studio

Tags: CI, Git, NuGet, TeamCity, Visual Studio

Tags: CI, Git, NuGet, TeamCity, Visual Studio



This post describes the setup of NuGet package inside TeamCity and configuration of your Visual Studio to consume the hosted packages. TeamCity version 7.1 is used.

When you work on a big or medium projects you’ll end up having at least one common library. If you keep everything in one solution then you don’t have problems with sharing the common library – you reference the common project to all other projects which need it.

How about the case when you have multiple separate solutions/projects and want to use the common library. In this cases you have two options: a) add the common library into all the projects as Add Existing Project and b) add a reference to the common dll file. With both approaches you have tackle a set of issues, like how to update the common library and not to break the projects using it; what if you need to use it for a project in a location different to the library, let’s say common library is located on c:/project but the project using it is located on D:/WebSites. These are just a few issues but enough to give you a headache.

All these issues will go away by implementing your common libraries as NuGet packages. You can host these packages on the NuGet web site but you might not want to do it. Here I explain how to host them in TeamCity.


Pre NuGet Build Configuration setup

Will start with standard build configuration steps. In TeamCity create a new Build Configuration. Set the Build number format as it will help to keep track on the versioning and make the update process easier. Set Version Control settings.

Add a Build Step which will build your package solution. If needed add /p:Configuration=Release to Command line parameters to build the release.

Add a unit test build step if it is the case. For example select the MSTest as Runner type if you do MS Unit testing. Add the following **\bin\**\*.Tests.dll in the List assembly files.


NuGet package configuration

Next is the part which is most interested for us. But before that make sure you have the NuGet set in Administration > NuGet Settings.

Add a new Build Step and in the Runner type select NuGetPack. If you set the NuGet settings you should have NuGet.exe dropdown with the NuGet version.

In the Specification files select the project you want to create a package from.

Update Version to %build.number% if you want to keep the same version you set in General Settings of your build configuration.

Set the Output Directory. For instance, Build\packages

Make sure you check the Publish created packages to build artifacts.

Also you might want to check Include sources and symbols but not mandatory.


In the Build Steps screen add AssemblyInfo patched in Additional Build Features so it will update the dll version in order to keep your files versioned.

That's all you need to set for TeamCity to create NuGet packages.


Visual Studio configuration

Next we need to configure VS to get the package from TeamCity.

In VS open Tools > Library Package Manager > Package Manager Settings. Select the Packages Sources and click the "+" to add a new sources. Give it a name and set the Source. If you haven't figured it out go into TeamCity > Administrator > NuGetSettings > NuGet Server and get the URL, either Autenticated Feed URL or Public Feed URL, depending how you configured it.

In order to add the common library to your project follow the same steps you do when you add a standard NuGet package to your project except you'll see now an additional repository - the one you’ve just created. That’s it – you now have your own NuGet package repository and you can add it to all your projects.


Using NuGet without committing packages to source control

When you add the NuGet package to your solution it will be added to your source control. So all the dll files will be committed to the source control. Starting with NuGet version 2 you have the option to download the library when you compile so the missing libraries will be downloaded on demand instead of keeping them on the source control. In order to enable this in VS open Tools > Library Package Manager > Package Manager Settings and select General. Check the Allow NuGet to download missing packages during build. This should be done on every machine. Next right click on the solution which uses the NuGet packages and select Enable NuGet Package Restore.

When you enable NuGet Package Restore a new .nuget folder will be created. It contains NuGet.exe file. It is executed during the build process to install the missing packages. This file should be added to source control. So if you have all your *.exe files ignored make sure NuGet.exe is not excluded, otherwise the build will fail.



One of the best way of sharing your libraries is using NuGet packages. You need to setup a TeamCity configuration build and configure the Visual Studio to access it. This post describes the steps you need to follow.


comments powered by Disqus