Setting up TeamCity as a native NuGet Server
TeamCity 7.0 EAP (Early Access Program) was recently opened and one of the new features is the built-in support for NuGet. I recently blogged about setting up TeamCity to pack and publish NuGet packages via a plug-in and this plug-in is now included by default in TeamCity 7. However, the real new interesting feature is that TeamCity is now a native NuGet repository too!
Native NuGet Server?
Many of those that have been using NuGet, have most likely been using it to consume packages from nuget.org where there are currently over 3800 unique packages, most of which are open source.
What happens however if for some reason or another you do not want to submit packages to nuget.org? For instance, think that you want to use NuGet to modularize and distribute code inside your own organization, or create libraries for private consumption. In this case, publishing to nuget.org does not make sense. This leaves you with basically two options:
Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
Copy nuget packages to a local share and have everyone read off of that
Both of these options come with their own share of overhead. With the local share you now require sharing of folders and permissions. Setting up your own NuGet repository also requires managing permissions and whatnot separately. At the end of the day, its another service to manage.
Fortunately, you now have a third option: TeamCity. The same server that builds your projects, runs your tests, packs and publishes your packages can now also serve them. The best part of it is that it is so simple, that I had to take up the rest of this blog with the previous nonsense just to give it some meat.
Enabling TeamCity as a NuGet Server
I am not going to cover how to pack and publish packages in this post. All that is covered in detail in the previous post I wrote, so please read that first if you’re not familiar with the process. Enabling TeamCity as NuGet and making packages available consists of two steps:
1. Enable the server to be a NuGet server
Go to Administration | Server Configuration | NuGet tab
Click on the Enable button to enable it. The same screen with then display two different feeds: a public and a private one:
If by chance the Public Url is not available, you will probably see a message telling you that you need to enable the Guest account in TeamCity, which can be done from the General tab.
2. Make your packages be your Artifacts
Since TeamCity itself is going to be a NuGet server, the step to publish a package is no longer required. However, packing the package is. In this step (NuGet Pack Build Type), we can just configure the output for the package to point to some specific folder, for instance packages
We need instruct TeamCity to ouput the results of this folder as artifacts. This is done in the General Settings step of the Build Configuration
and with that, we’re done. Next up is to configure Visual Studio to consume from this feed.
Configuring Visual Studio
Although this step is optional, it is recommended to add your repositories to Visual Studio to avoid having to type long URL’s in each time you want to read from a specific package repository. To do this, click on Options | Library Package Manager | Package Manager Settings
We need to add a new NuGet Repository. I’ve called it Local TeamCity and the URL corresponds to the public URL provided to me by TeamCity in Step 1:
Notice that I have another entry which is Local TeamCity Auth which corresponds to the authenticated version.
Once we have this, we can now easily consume packages from our repository by merely specifying it in the Package Manager Console, either via the Combobox or explicitly in each call:
That’s all there is to it. By merely publishing our packages as artifacts, TeamCity now provides a full-fledged nuget server which opens up great possibilities when it comes to working and managing dependencies between projects. TeamCity is currently in EAP and much of what I’ve described here is in open to improvements. That is why your feedback is very important. Download 7 and start playing with it today. Let us know what you think.
Subscribe to Blog updates
Thanks, we've got you!
Kotlin DSL for Beginners: Recommended Refactorings
Imagine you have just switched your TeamCity project over to Kotlin DSL. Your builds run successfully, but what next? What small refactorings can you apply to your Kotlin DSL code to help keep it clean and tidy? In this article, we'll discuss the next steps you can take. 1. Remove disabled build st…
TeamCity integration with .NET, Part 3: Deploying projects
Today we are wrapping up our .NET integration demo. In this series, we've been explaining how TeamCity can integrate with .NET and walking you through a tutorial. To catch up with the demo, read the previous posts: Part 1: New approach and demo Part 2: Testing and building projects This project ha…
New TeamCity REST API documentation
TeamCity REST API is a powerful tool which lets you integrate external applications with the TeamCity server and create diverse script interactions. To make this instrument more useful and easier to understand, we have reworked the REST API documentation. Compared to a general guide we had in the p…
TeamCity integration with .NET, Part 2: Testing and building projects
In this blog series, we talk about the new approach we use to integrate TeamCity with .NET. Part 1 describes the .NET runner, that covers most of the core integration functionality, and introduces a demo project. In Part 2, we will dig deeper into the demo project and explore its Test and Build conf…