Private, easily installable library packages with NuGet and MyGet

Most, if not all, software development organizations have their own set of standard tool libraries, and Offbeat Solutions is no exception. We’ve only been at this for about a year, and thus far we’ve rolled up just one, a generic tool belt that we unimaginatively called “oblib”. Smile Now, while libraries are fun, managing the installation of libraries can suck major donkey. So enter NuGet, the fledgling package manager from Microsoft. NuGet, and particularly its Visual Studio extension makes it ridiculously easy to install your favorite libraries. Wouldn’t it be great if your private tools were just as easily installable? Who says they can’t be? Let’s do this thing! If you’ve installed ASP.NET MVC 3 tooling for Visual Studio, you’ve already got the NuGet extension. If not, install it from Visual Studio Gallery. [Note: if you already have NuGet installed, you may want to check the Extension Manager for updates – the early versions didn’t always play nice with MyGet authentication] NuGet packages are relatively simple beasts. You build the packages by creating a manifest file containing some metadata about the package in question, point the command line tool NuGet.exe at the metadata file and… that’s about it. Doesn’t sound too hard, so let’s give it a whirl! Let’s start by getting the command line tool. Open the project you want to package, go to Solution Explorer in Visual Studio and right-click on the References node. There should be an option titled “Manage NuGet Packages…”:

Visual Studio solution explorer

Click on the menu item, and up pops a dialog. On the left side of the dialog, expand the “Online” section, and then type “nuget command line” to the search field in the top right corner. That should bring up a package named NuGet.CommandLine:

Manage NuGet Packages dialog

Click on the “Install” button next to the package. Visual Studio should work for a moment, and then you can close the dialog. At this point, there should be a folder named “packages” at the root of your solution, containing the package we just installed. Now that we’ve got the command line tool, let’s create the package manifest, also known as a NuSpec file. Open up a command prompt (I prefer PowerShell) and go to the project directory. Invoke NuGet by calling packages\NuGet.CommandLine.1.5.21005.9019\tools\NuGet.exe spec path\to\yourlibrary.dll (adjust paths by taking into account your version of the command line package and the path to your compiled library):

Creating a nuspec file in PowerShell

This should produce a file starting with the name of your library, ending in .nuspec. Go back to Visual Studio, include the file in your solution and open it up in Visual Studio. It should look something like this:

<?xml version="1.0"?>
     <releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
     <copyright>Copyright 2011</copyright>
     <tags>Tag1 Tag2</tags>

Fill in something sensible, then save the file and close it. Go back to your command shell, create a directory called “release” and then call NuGet.exe pack yourlibrary.csproj –Build –OutputDirectory release:

Building a NuGet package in PowerShell

Et voilà, we’ve got a NuGet package! Now, let’s make that a part of the build process. Unload the project in Visual Studio, and open the project file in the source editor. Add this as the AfterBuild task (adjusting for paths again):

  <Target Name="AfterBuild">
       <RemoveDir Directories="$(ProjectDir)\release\" />
       <MakeDir Directories="$(ProjectDir)\release\" />
       <Exec Command="$(SolutionDir)\Packages\NuGet.CommandLine.1.5.21005.9019\tools\NuGet.exe pack $(ProjectFileName) -OutputDirectory $(ProjectDir)\release" />

Reload the project, rebuild it, and with any luck, you should have a “release” folder containing a shiny, new NuGet package. Now that we’ve come this far, the last missing step is to make the package easily available. To this end, we’re going to use MyGet, a service that provides hosting for private NuGet feeds. After registering, you can create a package feed, set permissions to it and generate an API key – you should probably go do that now. Smile At this point you store your API key for NuGet to use by calling NuGet.exe setApiKey [key] –Source [feed]/api/v1/:

Setting an API key for NuGet in PowerShell

(Note: In case the blank spaces in the screenshot look confusing – that’s where I’ve erased my API key from public scrutiny). At this point, it’s a simple matter of running NuGet.exe push [package] –Source [feed]:

Pushing a NuGet package with PowerShell

and adding your private feed to Visual Studio. Open up Package Manager Settings:

Library Package Manager menu in Visual Studio

Add your personal feed to the list of available feeds:


Once you’ve done this, you can install your package by opening up the “Manage NuGet Packages…” dialog again. At this point, if you configured your feed to require authentication, Visual Studio will prompt you for your user name and password. If you didn’t, you’ll get the feed contents straight away:


Clicking on “Install” will pop up a progress indicator, after which the deed is done, and the library is ready for use. This concludes our show! Of course, this is by no means the whole story. There’s a bunch of stuff to consider from this point onwards. Some of them include:

  • Package dependencies: when your package requires another package in order to work
  • API versioning: what sort of changes can you make without breaking clients
  • Automatic publishing from a CI server

But those are all topics for a later day.