In a previous post, we mentioned NuGet as great way to package up code for deployment, and that got us thinking about NuGet feeds.

NuGet Overview

In just about every Visual Studio project we create today, we will eventually find a need for a 3rd party library of some kind.

Managing these libraries has traditionally been a cumbersome process. It can be difficult to find available libraries, although Google does a good job, but it’s hard to find the latest version of libraries you’ve used and keep them updated.

That’s when NuGet comes to the rescue. NuGet is a Visual Studio extension that makes it easy to add, remove, and update libraries and tools in Visual Studio projects that use the .NET Framework.

What’s great about NuGet is that we can use it to package our own applications for publishing, which means it becomes a good tool for deployment.

This post won’t cover using NuGet, there’s some great information at, but we are going to explore some options for publishing NuGet packages once they’ve been created.

Public Publishing at

The public NuGet Gallery is the best place to publish if you’re producing a library, component or framework you want others to use. If however, you’ve just developed a bespoke website for a new client this not the place to publish to.

The NuGet Gallery currently boasts more than 10,000 packages and claims over 42 million downloads, so if you have something to share this will be your publishing target.

Publishing to this feed is pretty straight-forward, you need to

1.  Register for an account at

2. Grab the API Key, located in the “My Account” page. This is generated for you.

3. Open a command console and run the command:

nuget setApiKey Your-API-Key

4. Confirm you can view your NuGet package in the NuGet Gallery using the search or in the NuGet Package Manager in Visual Studio.

That’s it. There is however a word of caution, and here it is direct from Microsoft; does not support permanent deletion of packages, because that would break anyone who is depending on it remaining available. This is particularly true when using the workflow that restores packages on build.

Instead, supports a way to ‘unlist’ a package, which can be done in the package management page on the web site. When a package is unlisted, it no longer shows up in search and in any package listing, both on and from the NuGet Visual Studio extension (or nuget.exe). However, it remains downloadable by specifying its exact version, which is what allows the Restore workflow to continue working.

If you run into an exceptional situation where you think one of your packages must be deleted, this can be handled manually by the NuGet team. e.g. if there is a copyright infringement issue, or potentially harmful content, that could be a valid reason to delete it.

  1. Easy to setup.
  2. Publicly available.
  1. does not support permanent deletion of packages.
  2. Publicly available without a mechanism to restrict packages.

Hosting your own NuGet Feeds

There are several reasons you may want to host your own NuGet feed, but the most common two are;

1. You want to restrict access to the packages/libraries that your development team can use. E.g. filter the public NuGet gallery by creating your own.

2. You want to publish your own packages, but not have them publicly available.

If this is the case, then you’re going to want to consider creating your own NuGet Feed. To do this, you have a couple of options;

1. Shared Folders

Download packages from the NuGet gallery or package your own code with NuGet and then put the packages (.nupkg files) in a shared folder location. Network drives, DropBox or any other document sharing tool are great for this.  Then, simply add the shared folder location to the list of available package sources in NuGet package manager in Visual Studio.

2. Feed Server

Using IIS you can create and host your own internal or remote feed on a server. By adding the NuGet.Server package to an empty website project you enable the site to serve up the package feed using Open Data Protocol (OData).

Once you’ve deployed the site to an IIS server you can then access the oData feed by using a URL. e.g. http://yourdomain/nuget/

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.

Detailed instructions on both of these methods can be found at Hosting your Own NuGet Feeds.


1. Allows you to control/protect what packages are in the NuGet feed.

2. Ensures that packages are not available in the NuGet Gallery

3. Additional packages can be added and deleted from the feed using NuGet.exe


1. Requires additional configuration and some development.

2. Shared network drives will work, but are not ideal.

3. Only supports one NuGet feed, so all packages are available in one feed.

JetBrains TeamCity as a NuGet Server

In Version 7 of TeamCity, JetBrains added native support for the NuGet Server.

Enabling the NuGet Server is easy. Select the “NuGet Server” option from the “Administration” section and click  the “Enable” button.

TeamCity NuGet Administration
TeamCity NuGet Administration

Once enabled the NuGet server URL’s will be shown.

TeamCity NuGet Server URL's
TeamCity NuGet Server URL’s

The public feed URL is only shown if the “Allow to login as a guest user” setting in “Global Settings” is ticked.

The final step is to add a build step, with a runner type of NuGet Pack. The NuGet Pack build runner allows you to create a NuGet package from a given nuspec file.

TeamCity NuGet Pack Build Type)
TeamCity NuGet Pack Build Type

Then, simply add the feed server URL to the list of available package sources in NuGet package manager in Visual Studio.


1. NuGet package creation becomes part of the build process.

2. NuGet server is integrated into TeamCity. No custom configuration or development is required.

3. Supports both authenticated and unauthenticated access to the NuGet server allowing for greater control.


1. Requires TeamCity.

2. Only supports one NuGet feed, so all packages are available in one feed.

3. Multiple feeds would require multiple TeamCity instances.


MyGet is a hosted NuGet feed, NuGet-as-a-Service (NaaS). The product has some really nice features, allowing you to create public and private feeds, apply fine-grained user security and also has a range of package management features, such as retention policy.

There is a free plan, but as with all -as-a-service offerings there is a price to pay, ranging from $7 USD/month to $599 USD/year for the Enterprise plan.

We’ve done some basic tests and the product works well. They certainly, consider themselves a SaaS provider, hosting on Windows Azure and making Uptime Status reports available, which is great to see.

What interested us most are two BETA features MyGet are currently running; Build Services and Package Sources.

Build Services

MyGet build services allows you to add packages to your feed by providing Git, Mercurial or Subversion repo details. MyGet servers download the code, build the package, create the package and  publish it.

Currently this service supports Microsoft.NET framework up to Version 4.5 and supports build hooks (commit build triggers) which can be linked to GitHub or BitBucket repositories and will trigger a new build using a HTTP POST.

Package Sources

Package sources are upstream repositories for your MyGet feed. You can aggregate package sources in a single MyGet feed, filter each of them individually, and even proxy upstream package sources to include them in your feed queries.


1. Supports multiple feeds, so packages can be separated into distinct groups.

2. Fine-grained security

3. Hosted solution means you don’t have to set up your own infrastructure

4. Extended feature set. Features and more in beta.


1. Private feeds are not free as shown in Pricing Plans.

2. Unsure of customer uptake.

Inedo ProGet

ProGet is an on-premise NuGet package repository server.

This product has some nice features which include multiple feed support, feed filtering (only in Enterprise), granular security and package caching.

The product has 3 licensing options;

1. Free, with limited support and some feature limitations.

2. Enterprise Annual $395 USD/year.

3. Enterprise Perpetual $995 USD/ 1st year, with additional support at $195 USD /year.


1. Supports multiple feeds, so packages can be separated into distinct groups.

2. Fine-grained security

3. Additional features when compared to the roll-your-own server solution.


1. Requires additional infrastructure to setup, including SQL Server, but will run using SQL Express.

2. Feature limitation in free edition, as shown in licensing.

NuGet Summary

We hope that gives you a flavor of the NuGet package hosting solutions available. Each solution has advantages and disadvantages, but our advice would be;

1. If you’re creating a library to be used by developers in the public domain, choose NuGet Gallery.

2. If you’re using TeamCity, use the inbuilt NuGet Server. It’s real easy.

3. The choice between Local Feed Servers, MyGet and Inedo ProGet is a close call, but our winner was MyGet. The beta features,  Build Services and Package Sources made it our choice.


Automated release management for .NET with OctopusDeploy

Introducing OctopusDeploy

We are big fans of OctopusDeploy and have been using it since its beta release in early 2012. If you’re not familiar with OctopusDeploy, here’s the background;

1. It’s an automated release management tool for Microsoft .NET, comprising of a centralized server and agents, known as Tentacles, which are installed on each target server.

2. It uses the NuGet package format,  an open source package manager for the Microsoft .NET Framework.

3. Tentacle agents listen on TCP port 10933 by default and HTTP requests are encrypted using a pair of X509 certificates.

The following diagram shows the release management components;

Deployment Components
Deployment Components

Release Management On-premise or Off-premise

One of the highlights of using OctopusDeploy is its’ ability to deploy software to servers located in any environment. The highlight reel goes a little something like this;

Whether your servers live in the cloud, in a data centre, or under your desk , Octopus can securely upload, install and configure your applications.

Just install a tiny service agent called Tentacle on your servers, and then use our easy installation wizard to set up a secure connection between the Octopus and Tentacle based on public/private key encryption technology. Your server is ready for deployments!

We’ve installed OctopusDeploy many times and have used some of the following installation scenarios to deploy to on-premise and off-premise data centres.

Scenario 1: On-Premise Installation with On-Premise Deploy

One of the more common ways of installing Octopus is one where the NuGet Server and Octopus Server are located on your own network,  along-side Continuous Integration servers or source control systems.

In this installation, OctopusDeploy will pull NuGet packages from a NuGet Server (such as MyGetJetBrains TeamCity, a NuGet Feed Server or just a local file path) and push the deployment out to target servers located on a local network.

Since all servers are located on the same network, this configuration is straight-forward and requires not much more than Windows Firewall configuration to be completed,  where TCP traffic over port 10933 (presuming the default ports) is allowed between the OctopusDeploy server and the target servers.

On-Premise Installation with On-Premise Deploy
On-Premise Installation with On-Premise Deploy

Scenario 2 :On-Premise Configuration with Off-Premise Deploy

This installation presumes that your target servers are not within your own network. E.g. hosted in an off-premise data centre E.g. a cloud environment. Configuration is the same as Scenario 1, and Windows Firewall will still need to be configured.

However, in this scenario it is likely that additional layers of security will be in place E.g. a hardware firewall. Network teams will need to ensure that TCP traffic on the OctopusDeploy port (10933 by default) is allowed into each server.

This deployment scenario has some complications however. Each target server needs to be publicly addressable. For load balanced server farms this is going to add a level of complexity, as firewalls and content switches/load balancers will need to be configured to allow each target server to be individually and publicly available to an external caller.

More common, is the fact that servers located in the off-premise data centre might not be publicly addressable with good reason. E.g. Web Servers in a DMZ can receive traffic originating from public networks, whereas application and database servers (and firewalls) are configured only to receive traffic generated within the off-premise data centre.

If you do decide to expose servers publicly to allow Octopus to deploy from an on-premise to an off-premise location, you can take some solace from the fact that the Paul Stovell from OctopusDeploy has ensured deployment is secured with HTTP requests that are encrypted using a pair of X509 certificates.

On-Premise Configuration with Off-Premise Deploy
On-Premise Configuration with Off-Premise Deploy

Scenario 3 :Off-Premise Installation with Off-Premise Deploy

Finally, you might want to consider a scenario where the Octopus Server is hosted within the off-premise data centre that software will be deployed into.

The NuGet server can remain on-premise in this scenario. Since Octopus will generate outbound HTTP (TCP:80) traffic to a known destination ( in our experience ), security guys (not all) are cool (don’t complain complain less) with this approach.

Advantages over Scenario 2

1. Octopus and target servers are now located within the same network, or are on trusted networks.

2. Servers do not have to be made publicly addressable. Non public servers can be deployed to.

3. Load balanced challenges in Scenario 2 are overcome. Octopus can now individually address all servers.

4. Deployment time can be reduced, as NuGet packages are transferred once from NuGet source and are deployed across local or trusted networks.


1. Additional server infrastructure is required in data centre to host OctopusDeploy Server.

Off-Premise Installation with Off-Premise Deploy
Off-Premise Installation with Off-Premise Deploy

We hope that’s given you a flavor of the installation scenarios available to Octopus Deploy! More information on OctopusDeploy can be found at

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.


We are uncovering betters ways of interacting between development and operations, by doing it and helping others do it.