NuGet is a valuable tool for managing references to external libraries in your projects. If you’re not using it yet, you owe it to yourself to try it out and see what you’re missing. Though, that’s not what this post is about. Not only are NuGet packages a great way to distribute publically available libraries, they can be used just as well for custom internal libraries with their own release management which are used in multiple projects. Since there’s a lot of information already available on this topic, instead of repeating it I’ll rather link to it from one place and add a few helpful hints and tricks along the way.

The first step is to create a NuGet package from your library. To do it you need NuGet.exe, it’s not enough to have NuGet Package Manager Visual Studio extension installed, neither is that necessary when this step is being done on your build server. Although it is possible to create a package directly from a Visual Studio project, I strongly suggest to put in a little extra effort from the beginning and use a convention based working directory instead. It gives you many more options which you’re going to miss very soon if you do it the easy way. Don’t forget to set the correct version in the manifest file during each build -  it is only done automatically for you when using a project file as the source. This short NAnt task should do the trick (CCNetLabel property contains the desired version since this is being built with CruiseControl.NET):

<xmlpoke file="MyLibrary.nuspec"
         xpath="package/metadata/version"
         value="${CCNetLabel}" />

Once *.nupkg files are being generated on every build of the library, it’s time to set up an internal feed to distribute them. While it is possible to host a proper feed in IIS, a poor man’s version in the form of a file share will work just as well. Just create a shared folder somewhere on your network (e.g. \\buildserver\NuGet) and copy every generated package file into it. Now you can instruct your developers to add this feed to their NuGet configuration and they can start referencing your libraries the same way they are already used to with libraries from the official NuGet gallery:

You could already stop at this point but I’m convinced that you should go one step further and take care of package restore to avoid putting the libraries in your source control system. There are only three easy steps to follow:

• Open Package Manager Console Window (Tools > Library Package Manager > Package Manager Console menu item in Visual Studio with NuGet Package Manager installed).
• Run the following commands:

Install-Package NuGetPowerTools
Enable-PackageRestore

• Instead of the packages folder put the .nuget folder into source control (both are inside the solution folder).

Once this is done, NuGet will always make sure the correct versions of all the packages are present locally before the build starts. There’s even no need to have NuGet Package Manager installed for this to work. There’s only one more change required to make this work flawlessly with the internal feed that we have set up. Open up the NuGet.targets file in the generated .nuget folder and add this feed to the PackageSources property group:

<PackageSources>\\buildserver\NuGet -source https://go.microsoft.com/fwlink/?LinkID=230477</PackageSources>

Without this modification the package won’t be found if NuGet is not properly configured for the user the build is running under (the package sources configuration is stored in %APPDATA%\NuGet\NuGet.config). The second feed in my case is the official one which you should always add as well so that the public libraries can still be found.