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.

image

 

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:

 

  1. Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
  2. 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

 

image

Click on the Enable button to enable it. The same screen with then display two different feeds: a public and a private one:

 

image

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

 

image

 

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

 

image

 

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

 

image

 

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:

 

image

 

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:

 

image

 

 

Summary

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.

4 thoughts on “Setting up TeamCity as a native NuGet Server

  1. mastoj

    This is really great stuff but I have some questions. Where are the packages saved on the nuget server? Is there a way to upload external packages not built by TeamCity to this feed?

    Reply
    1. hhariri Post author

      They are stored on the server alongside the artifacts. The only way right now to do the external packages would be to setup a project that copies and publishes them as artifacts pretty much. So yes, it’s possible.

      Reply
  2. mastoj

    This is great stuff but I have some questions about it: Where are the packages stored on the build server? Or are teamcity just using the artifacts from the builds? Is it possible to upload external packages to the feed?

    Reply
    1. hhariri Post author

      They are stored in the same place where the artifacts are. Also, you can add any external package as a build config and publish.

      Reply

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