NuGet'ing inside the firewall, with TFS Continuous Integration bonus power too (or "How to go from TFS CI to your Private NuGet server with TeamBuild")

DK Development - From TFS to Private NuGet

"Let me start by saying this: I love NuGet, its straight up awesome!

This post is about how I created a TFS CI Build to create NuGet packages and push them to a private NuGet server hosted on site.

I have been playing around with the TFS Build server, mainly for a Continuous Integration (CI) build on some of our projects and I wanted a way for me to be able to update a core library and have it propagated to all of the projects that use that library without them all needing to be in the same solution.

The answer was a private NuGet server with a CI build that automatically packaged my library.

I started by setting up a private NuGet server, reading Phil Haack’s post about hosting a simple package feed. Once that was done I could start pumping out packages!

Now that I have my NuGet server I need to setup the build. I created an Ardent.CommonBuild.proj for my build config and tasks. I found its easier to manage as a separate file to the actual project file, this file has to be a .sln or .*proj file for the TFS Build server to be able to run it.

...

..."

As I've said before I believe NuGet could be that in-house "Repository" we've long been looking for (do you remember all those promised code/library/component repositories in the 90's and 00's? The services that would solve all our sharing problems, end world hunger and bring peace to mankind? That never actually worked out in the real world? Yeah... me too...). I won't rehash my comments this, but let me just say that every week I'm seeing more proof that NuGet might have us finally on the right track, proof as in the above post.

In three words, NuGet just rocks