Self-Hosting NuGet

Question

I have been looking at self hosting NuGet, having a hard time understanding how to set it up and how it would help support our development process.

Does anyone have any recommendations as to which to use, how to set it up?

Or should I just use a hosted service?

Riki

Answer 1

After looking around at various solutions--self-hosted and hosted service--we chose to go with ProGet.

ProGet Summary

ProGet has a standard "free" license and nominal licensing fees (single year and perpetual) for the enterprise version. We currently use the standard "free" version and have no real complaints. You can create as many feeds as you want, add as many users as you want, etc. (We created "Testing", "Staging", and "Production" feeds to be part of our quality assurance process.) The only real limit in the free version is the inability to filter external feeds for specific packages you want included in your ProGet feeds. This filtering feature is managed with "connectors". With the enterprise version--when you create a feed--you can optionally add a "connector" to pull in packages from other feeds (external or internal).

ProGet With Nuget Package Management and Creation

The steps for creating a nuget package itself I'll leave to David Ebbo's popular blog post, http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-packages-with.html. However, know that for uploading packages you can upload via the ProGet packages administration web UI, command-line nuget.exe, or the Nuget Package Explorer.

ProGet Installation, Configuration, and Activation

Installing, configuring and activating ProGet was the least intuitive part. It can install backed by a regular SQL Server database or a SQL Server Express db. Furthermore, it can also be a self-hosted app or run under IIS. If you need to perform offline activation or want to request different license keys go to my.inedo.com and create an account and you can do everything from there.

Proget Quality Control & CI

CI with TeamCity is something we are going to need so we are looking at creating a nuget package build process using TeamCity's Nuget server. There's a how-to for creating the packages I'll post in a comment. The next step would be to automatically publish the TeamCity-created nuget packages over to the appropriate ProGet feeds (ie. "Testing", "Staging", "Production") perhaps utilizing command-line Nuget with an API key.

Further Information

We looked at MyGet as a hosted service but it seemed to trip up on simple scenarios like adding another contributor/user. It also jumped quite a bit in price when needing more than just two contributor accounts. Whereas with ProGet you get unlimited user accounts with the free version alone.

One more side note: For publishing OSS type projects/packages, I'd take a look at Chocolatey as a solution.

Unopened

Here's the link to the "how-to" as promised: jamesheppinstall.wordpress.com/2012/05/25/… – Unopened

Typically our install/activation process is very straightforward. The only time you need to go outside the tool for activation is if the ProGet server is not connected to the internet, typically the activation is automatic. I will also add that the Enterprise version also adds the ability to use LDAP for feed access instead of having to manually remember or enter an API key (unless of course one is specified explicitly for the feed). – Agha

Tod messaged me with regards to the link issue and those are now working again. – Grory

Thanks Tod and John. So far we've really appreciated the flexibility of the tool. Knowing you guys are so responsive to user/customer needs is very encouraging as well. We are looking at purchasing an enterprise license in the near future. – Unopened

I have tried ProGet too, but it was very unreliable and we had heaps of problems with it; randomly disallowing access, forgetting packages, taking ages to display packages in VS. – Fairfax

@Fairfax - almost a year later, any of those issues that were ProGet-related should have been resolved now as the way packages are stored has completely changed. Previously, packages were monitored using a FileWatcher, whereas now our own monitoring service is used which is far more reliable, especially with packages stored on network drives. Also, all local package indexing is now done in the SQL database, and we have several users with 10k+ packages that do not notice any slow display or download times. – Grory

@JohnRasch Yes, we are a happy customer of Inedo now :) – Fairfax

Answer 2

Another option for self hosting is using the NuGet.Server package and creating an IIS website to host it on your internal network, although it won't scale very well if you plan to publish more than a handful of packages.

I've created a fork of NuGet.Server that uses a Lucene.Net index to fix these performance issues. Downloads are available from https://github.com/themotleyfool/Klondike/releases.

Conners

How many packages before it no longer scales? Which version did you last test with? Have your forked changes been merged back into the official source tree? – Graven

@ShaunWilson I probably last tested with NuGet.Server 2.0, but looking at the code it hasn't changed much. The primary scaling problem is that package hashes are cached in process so when the app recycles every package on the filesystem has to be read in entirety to recalculate the hash. Search and list operations are also slow for similar reasons. – Conners

@ShaunWilson I found in testing that NuGet.Server was basically unusable at around 100 medium size packages. My fork has not been merged back upstream because it has too many changes. It is now a separate project called Klondike, available at github.com/themotleyfool/Klondike – Conners

Answer 3

To keep this thread up-to-date, Visual Studio Team Services also has a package manager in preview. See the marketplace: Package Management

Keystroke

Answer 4

You can create an empty Asp.Net Web Application and install Nuget.Server from Nuget Gallery. This is a free option of self hosting your own Nuget packages on IIS. Check the documentation

Indescribable