Set up your own NuGet gallery with SymbolSource

So far there have mostly been instructions on creating local or remote-but-read-only NuGet feeds. You can read about it in a few places, like these:

This method, although very simple, unfortunately has a big drawback: you can't publish packages with nuget.exe, so none of the new SymbolSource integration goodness will be available to you.

But since the sources of all components that drive the NuGet website and package feed can be downloaded from Codeplex, you can set up the exact same experience with a separate, private data store. Before we dive into the 8 step instruction that follows, let's establish our goal. Imagine for a moment that you work at the same company that I do, which is called Caliper, and that we have a server called Polaris. At the end of step 8 you should be able work with internal NuGet packages the same way you do with with regular ones:

  • nuget.exe list -source http://polaris/nuget-server/FeedService.svc
  • nuget.exe push SecretLibrary.0.1.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://polaris/nuget-server
  • nuget.exe push SecretLibrary.0.1.symbols.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source

Of course, you'll be also able to use our clone of the site and install and debug packages right from Visual Studio.

Interested? Then let's get going.

Step 1: Getting the sources

There are a few repositories that you will first need to clone with Mercurial:

  1. GalleryServer ( - this is a backend application containing the package feed - both nuget.exe and the frontend site use it to list, download and publish packages.

  2. Orchard.Gallery module ( - this is an Orchard module that runs the frontend sites - (with Packages) and (with Modules and Themes).

  3. Orchard ( - unless you've been on some exotic trip for the past few months (in which case I envy you a lot), you must have heard about Orchard - it's an extensible CMS platform built in .NET, and we'll need it to run the Orchard.Gallery module.

  4. OrchardGallery theme ( - this is the theme, but it's also required for a NuGet gallery.

  5. NugetGallery theme ( - this is the theme built on top of the OrchardGallery theme.

Step 2: Building projects and preparing a site structure

The next step is to build the downloaded sources, but before you do that you need to switch Orchard to the correct revision. This is taken from the Readme.txt file of the Orchard.Gallery module:

The Orchard.Gallery module is currently being developed against the 1.x branch of the Orchard repository, changeset number: 4406 (7caba1cd1dcd).

Being new to Mercurial I had some trouble finding the way to do this, so if you are using TortoiseHg, I suggest having a look at the Update... context menu item. Once you switch to revision 4406 it should look like this:

Switching to revision 4406

To build the necessary components:

  • Run ClickToBuild.bat in GalleryServer.
  • Run ClickToBuild.cmd in Orchard.
  • That's it, all the other required modules and themes will be built automatically at run-time by Orchard.

Step 3: Configure IIS to run Orchard

The actual web application that you will be running is in src\Orchard.Web. I named it nuget-gallery and placed it in C:\WebSites\nuget-gallery, so that's what you'll see on the screenshots, but the naming is all up to you.

Before going further, modify Web.config to run Orchard under full trust. Change <trust level="Medium" originUrl="" /> to <trust level="Full" originUrl="" />. This is required by the Orchard.Gallery module.

Now you can run IIS Manager and configure the web application. Right click Default Web Site and select Add Application....

IIS Manager

Be sure to select an application pool configured to use ASP.NET 4.0.

Adding the nuget-gallery application

Step 4: Run the Orchard site and install required modules

At this point you should be able to access the Orchard site. In my case this was at http://polaris/nuget-gallery. During the first run you can configure the name of you site (I went with Caliper NuGet Gallery, since that's the name of our company) and set a password for the admin user (at least 7 characters). For now I suggest using the default SQL Server Compact Edition option to save on additional work.

Now go to the Dashboard, pick Modules in the side menu and install the following modules (order is important because of compile-time dependencies):

  1. Profile
  2. Taxonomies
  3. Voting
  4. Contrib.Reviews

After that you can add modules and themes downloaded earlier.

  • Copy the Orchard.Gallery module to C:\WebSites\nuget-gallery\Modules. Note that the name of a module folder is important.
  • Copy OrchardGallery and NugetGallery themes to C:\WebSites\nuget-gallery\Themes. Names of theme folders are also significant.

Now you can go back to the Dashboard, this time picking Features, and enable Orchard.Gallery. This will also enable all dependencies.

Step 5: Configure Orchard and Orchard.Gallery

The next step is to go to Taxonomies and decide if you want to host NuGet packages only or also support Orchard modules and themes. We build Orchard applications so I just added a Packages entry to have all three.

Configuring the package taxonomy

It's almost time to set up the backend now, so have a look at Settings in the Dashboard.

Orchard settings for a gallery site

First of all you might want to enable user registration or perhaps even require e-mail verification. If you do enable the latter, be sure to configure SMTP settings that are just below where I clipped the screenshot.

Next, in Gallery Settings you need to configure the location of the backend GalleryServer application. I decided to host it on the same server under /nuget-server.

Note that you won't be able to save settings unless you fill out the User To Report Abuse To field. Additionally, this needs to be a different user than admin - you will need to create one yourself.

Step 6: Configure GalleryServer

GalleryServer also uses SQL Server Compact Edition and creates a database on-the-fly like Orchard, but since it uses Entity Framework (whereas Orchard relies on NHibernate) and a crucial assembly - System.Data.SqlServerCe.Entity.dll - is not present anywhere in the source tree, you will need to either install SQL Server Compact 4 on the server or get the assembly elsewhere and copy it to bin.

Next configure the site in IIS. In my case this is /nuget-server pointing to C:\WebSite\nuget-server, which is a copy of the entire GalleryServer repository.

Because GalleryServer relies on the Orchard.Gallery module for authentication and authorization, you also need to modify ApplicationSettings.config. In my setup the relevant settings are as follows, the rest is left an modified:

Unfortunately, FrontEndWebSiteRoot can only contain the hostname, so you need to repeat the entire path in each setting.

Step 7: Test the setup with nuget.exe and the frontend website

Now you can finally see if things are really working. As a smoke test, first try getting the list of packages (which will obviously be empty, but shouldn't return any errors):

nuget.exe list -source http://polaris/nuget-server/FeedService.svc

Then log into the site as a non-admin user (you can can use the one created for the Settings page). In the usual place - MyAccount - you'll find your local API key. Now try uploading a package:

nuget.exe push elmah.1.1.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://polaris/nuget-server

Next check if it's really there:

nuget.exe list -source http://polaris/nuget-server/FeedService.svc

Now go back to http://polaris/nuget-gallery and check the My Contributions page and the global Packages page. Note that the latter sometimes needs a few minutes to refresh.

If all tests succeeded - congratulations! You are now a proud owner of your own private NuGet gallery. At this point you can use both nuget.exe and the website for all package operations, including upload and removal.

Step 8: SymbolSource integration

This is all great, but I hope you are now asking a very important question: how do I make use of the SymbolSource integration features introduced recently into NuGet?

SymbolSource has been built from the ground up with scalability and multi-tenancy in mind. Although we are not yet ready to release a standalone product that you could install on your own server, we can provide you with an entirely separate repository of symbols and sources.

You might have noticed that many of our URLs containt a Public prefix or suffix. This is a so-called company name and it identifies a separate namespace for users and packages. You can actually have a look at our NuGet symbol and source repository here (access to demo projects is unrestricted):

The functionality of a private instance of SymbolSource is the same as the public one, and you can use it in the same way. For example, to upload a package, you can use this command:

nuget.exe push SecretLibrary.0.1.symbols.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source

And that's it. Absolutely no pain of the original Microsoft source indexing scripts, no need to take care of file system performance, and out-of-the box support in NuGet and Visual Studio. During upload, the correct NuGet gallery will of course be consulted to verify that you are a contributor for the particular project. To debug a package, all you need to do is add a familiar looking URL to Visual Studio:

This is a private URL, which means that it contains a username and an authentication hash. No symbols or sources will be served out publicly.

What I've described so far in this blog post is a setup that we use in our everyday development. If you are interested in an environment like this, contacts us on Google Groups, Twitter or using the comment form below.

The next post will describe how SymbolSource handles permissions and how symbol and source access to repositories and projects can be restricted per user.

Posted by Marcin Mikołajczak (TripleEmcoder) on Friday, April 22, 2011

blog comments powered by Disqus