Scott Hanselman

How to host your own NuGet Server and Package Feed

April 13, '16 Comments [43] Posted in NuGet | NUnit
Sponsored By

Local NuGet FeedHosting your own NuGet Server, particularly when you're a company or even a small workgroup is a super useful thing. It's a great way to ensure that the build artifacts of each team are NuGet Packages and that other teams are consuming those packages, rather than loose DLLs.

A lot of folks (myself included a minute ago) don't realize that Visual Studio Team Services also offers private NuGet Feeds for your team so that's pretty sweet. But I wanted to try out was setting up my own quick NuGet Server. I could put it on a web server in my closet or up in Azure.

From the NuGet site:

There are several third-party NuGet Servers available that make remote private feeds easy to configure and set-up, including Visual Studio Team Services, MyGet, Inedo's ProGet, JFrog's Artifactory, NuGet Server, and Sonatype's Nexus. See An Overview of the NuGet Ecosystem to learn more about these options.

File Shares or Directories as NuGet Server

Starting with NuGet 3.3 you can just use a local folder and it can host a hierarchical NuGet feed. So I head out to the command line, and first make sure NuGet is up to date.

C:\Users\scott\Desktop>nuget update -self
Checking for updates from https://www.nuget.org/api/v2/.
Currently running NuGet.exe 3.3.0.
NuGet.exe is up to date.

Then I'll make a folder for my "local server" and then go there and run "nuget init source dest" where "source" is a folder I have full of *.nupkg" files.

This command adds all the packages from a flat folder of nupkgs to the destination package source in a hierarchical layout as described below. The following layout has significant performance benefits, when performing a restore or an update against your package source, compared to a folder of nupkg files.

There's two ways to run a "remote feed" handled by a Web Server, rather than a "local feed" that's just a file folder or file share. You can use NuGet.Server *or* run your own internal copy of the NuGet Gallery. The gallery is nice for large multi-user setups or enterprises. For small teams or just yourself and your CI (continuous integration) systems, use NuGet.Server.

Making a simple Web-based NuGet.Server

From Visual Studio, make an empty ASP.NET Web Application using the ASP.NET 4.x Empty template.

New Empty ASP.NET Project

Then, go to References | Manage NuGet Packages and find NuGet.Server and install it. You'll get all the the dependencies you need and your Empty Project will fill up! If you see a warning about overwriting web.config, you DO want the remote web.config so overwrite your local one.

Nuget install NuGet.Server

Next, go into your Web.config and note the packagesPath that you can set. I used C:\LocalNuGet. Run the app and you'll have a NuGet Server!

You are running NuGet.Server v2.10.0

Since my NuGet.Server is pulling from C:\LocalNuGet, as mentioned before I can take a folder filled with NuPkg files (flat) and import them with:

nuget init c:\source c:\localnuget

I can also set an API key in the web.config (or have none if I want to live dangerously) and then have my automated build push NuGet packages into my server like this:

nuget push {package file} -s http://localhost:51217/nuget {apikey}

Again, as a reminder, while you can totally do this and it's great for some enterprises, there are lots of hosted NuGet servers out there. MyGet runs on Azure, for example, and VSO/TFS also supports creating and hosting NuGet feeds.

Aside: Some folks have said that they tried NuGet.Server (again, that's the small server, not the full gallery) a few years ago and found it didn't scale or it was slow. This new version uses the Expanded Folder Format and adds significant caching, so if you've only see the "folder full of flat nupkg files" version, then you should try out this new one! It's version 2.10+. How much faster is it? First request to /nuget (cold start, no metadata cache) before was 75.266 sec and after is 8.482 sec!

The main point is that if you've got an automated build system then you really should be creating NuGet packages and publishing them to a feed. If you're consuming another group's assemblies, you should be consuming versioned packages from their feeds. Each org makes packages and they flow through the org via a NuGet server.

Important! If you are using a Network Share with NuGet.Server, make sure you have the newest version because this file folder structure can give you MAJOR performance improvements!

How do YOU handle NuGet in YOUR organization? Do you have a NuGet server, and if so, which one?


Sponsor: Big thanks to RedGate and my friends on ANTS for sponsoring the feed this week!

How can you find & fix your slowest .NET code? Boost the performance of your .NET application with the ANTS Performance Profiler. Find your bottleneck fast with performance data for code & queries. Try it free

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Wednesday, 13 April 2016 02:25:39 UTC
Been quite happy with Klondike (https://github.com/themotleyfool/Klondike), but our choice in going that route was mostly due to Nuget.Server's awful performance. On our roadmap is moving off of Klondike and back to Nuget.Server once we evaluate the performance. Hopefully Nuget.Server will also get proxy support for local caching of our packages too.
Philip Scott
Wednesday, 13 April 2016 02:28:35 UTC
I setup a ProGet server for our development team. Works great but I'm not going to lie the trickery I had to go through getting a CI process setup for it was challenging to say the least (TFS/MSBuild not ProGet). It has been great establishing this culture of reusable components to share across teams in our department.
Shawn
Wednesday, 13 April 2016 02:36:21 UTC
Philip - Klondike looks cool! I'll check it out!
Scott Hanselman
Wednesday, 13 April 2016 02:57:38 UTC
Is this just a packaged version of https://github.com/NuGet/NuGetGallery? We are running a fork of the github project at work and I wonder if there is any benefit to running this version instead.
Wednesday, 13 April 2016 04:54:52 UTC
Nice article Scott !!
Wednesday, 13 April 2016 05:20:30 UTC
We have our nuget feed in Octopus, which is our choice of deployment tool.
Henrik Olsson
Wednesday, 13 April 2016 05:33:37 UTC
We're using NuGet.Lucene, which is the base part of Klondike. We're using it because of the performance and the build-in symbol server.
Toni
Wednesday, 13 April 2016 05:45:29 UTC
Since 2014, We've gone exactly down the Empty asp.net project + NuGet.Server route. It's working well for us.

Shortly after we set that up, we set up a private symbol server also, using the SymbolSource.Server.Basic package inside another empty asp.net project.

We found we had issues trying to just use a single NuGet.Server host for both "normal" packages and symbol packages, since the server would accept both uploads but would then fall over when someone requested a package and it found it had two packages with the same name. (Plus the SymbolSource server actually unpacks the symbol packages and VS can retrieve symbols from it even when it's not aware that the DLLs originated from a NuGet package)
Damien
Wednesday, 13 April 2016 06:01:42 UTC
We've been using this approach (local folder on a local server) for a few years. It's a problem when we want to run builds in VSTS, since we've got a self issued SSL certificate on our NuGet server. We cannot install our certificate on the hosted build server, so we've started synching our local NuGet feed to the VSTS hosted NuGet feed. It would be great to have a VSTS hosted NuGet as fast as our own local server.
Wednesday, 13 April 2016 06:20:16 UTC
We use ProGet here - works fine as a NuGet-feed incl. a proxy for nuget.org (we only use the ProGet feed in our projects and ProGet proxies requests to nuget.org if it's not a "local package") and as a symbol server.
The tricky part for us was also getting MSBuild to create and deploy the packages during build - I ended up writing a small tool which is called in the post-build event which calls all the needed nuget pack/push commands and is configured via MSBuild parameters, because we also need to do some "version trickery" as our internal versioning schema is not directly compatible with NuGet's semver format.
Christoph Fink
Wednesday, 13 April 2016 06:27:54 UTC
We tried to set up a NuGet gallery (https://github.com/NuGet/NuGetGallery/wiki/Hosting-the-NuGet-Gallery-Locally-in-IIS) to allow teams to publish their packages for internal use, but this was more complicated than we had expected, and we did not have time to bring it to life (it was a side project). It was over a year ago, and from what I remember, setting up a feed was rather simple. Unfortunately, the feed is not enough for cross-enterprise code reuse. To get most of internal NuGet, you'd need to set up the check-in policy, manage the UI, etc, so this is where the gallery comes handy, and we spent several weeks (like lunch time and extra hours here and there), trying to make it work. We made some progress, though, but not enough for actually making it work. I hope that some day we get back to it, and finish implementing the gallery with less effort.
Wednesday, 13 April 2016 08:05:02 UTC
Do NuGet.Server and/or TFS allow the hosting of symbol files? At the moment, we're using the free version of Inedo's ProGet because they provide the possibility to host the symbol packages.
Ramon Pfeiffer
Wednesday, 13 April 2016 09:08:43 UTC
We use TeamCity which has a NuGet Server option that will provide access to the NuGet Packages(which are build artifacts)

There are various NuGet build steps available like 'NuGet Pack' and 'NuGet Installer' which produces the NuGet Packages and can restore packages from different NuGet sources: the public NuGet feed(https://www.nuget.org/api/vX) but also your own local TeamCity NuGet feed(%teamcity.nuget.feed.server%).
J. van Donk
Wednesday, 13 April 2016 11:00:10 UTC
I used ProGet as a NuGet server AND Symbol Server. Nupkg are build within the MSBuild process(with a good PowerShell). The PowerShell update the nupkg version and if it's not from the master branch in git, then publish a pre-release version. The Symbol server Is really neat to debug our packages.


Wednesday, 13 April 2016 11:27:48 UTC
+1 for TeamCity's Nuget Server and the built in Nuget artifact support. Works a treat.
Quooston
Wednesday, 13 April 2016 12:14:54 UTC
We tried the NuGet.Server package for a little while, but it was horribly slow when you had more than 100 packages/versions. This was back in the days of NuGet v2 though, so not sure if it's any faster in v3.

We're using MyGet now. It's working pretty well and we have a tonne of packages. Occasionally requests will fail, but probably no more failure rate than npm ;)
Wednesday, 13 April 2016 13:11:01 UTC
Having dealt with an internal ProGet server used for hosting a few local packages and otherwise being a proxy for the main Nuget feed, I'm afraid my experience was far from positive. Nuget seems to be slow at the best of times, and adding ProGet to the mix just made things even worse. This wasn't helped by the fact that our product probably wasn't complex enough to justify its being split into multiple packages in the first place.
Wednesday, 13 April 2016 16:24:07 UTC
We experimented with this previously using TeamCity but found it difficult to manage. VS's continued second-class support for NuGet certainly doesn't help. Whatever happened to making packages and DLLs both appear in a project's references list? Why is the NuGet pane still so slow and buggy? Why does the ASP .NET team push using alternative package managers instead of improving and consolidating around NuGet?

For now, it's much easier to add the projects you need to your solution and use project references.
Sam
Wednesday, 13 April 2016 18:41:28 UTC
+1 for ProGet. We run an instance at the Community level. It's hosted on an Azure VM that also doubles as our Jenkins server.

I don't recommend using ProGet as a proxy for the standard feeds. I've found several packages that simply don't show up through the proxy. I don't have any filtering on the feed (that I know of), but I also don't have the time to dig through the settings to see if I've done something wrong. But other than that, I'm extremely happy with it!
Terry
Wednesday, 13 April 2016 19:49:03 UTC
Philip Scott - I looked into this and there's been some VERY significant perf improvement in NuGet.Server. It's much much better (like near 10x) but you're right it won't search like Lucene. I think NuGet.Server is great for small groups.

Richard - I updated the post. The new NuGet.Server is WAY faster with v3.

Damian - Good catch. They fixed that in 2.10 by rejecting symbol-only packages. They also don't push symbol packages by default.
Scott Hanselman
Wednesday, 13 April 2016 21:23:02 UTC
When we started NuGet, we created our own TFS Xaml template that packed and pushed packages to a 'poor mans package source' (shated folder). Having a lot of packages and a lot of versions of that packages, the folder got to a size that listing or installing packages from that source got very slow.
We improved our process in several step, which results in the following mechanism: We now have a MsBuild task that packs a NuGet package after every release build. On the build server, the Xaml template pushes every package that it can find for the project that has just been build (of cause only at check-in time / gated check-in) to our new ProGet server (free).
Christian Grotheer
Friday, 15 April 2016 23:55:41 UTC
We just started hosting our internal NuGet feeds with TeamCity. For those that are using TeamCity, how do you handle versioning? Do you just manually change the production build configuration version when you're ready to release a library for production use? Or is there a better way to automate it?
Justin Butler
Saturday, 16 April 2016 04:40:47 UTC
How would you debug release a release compiled package (the dlls)?
Saturday, 16 April 2016 08:07:39 UTC
Can I use ASP .NET Core to make the web based server?
Thank you
ivan
Monday, 18 April 2016 07:20:27 UTC
Is there a way to get the latest nuget package when building a project in Visual Studio 2015?
Alvar
Monday, 18 April 2016 14:37:34 UTC
nice article thanks for sharing this information
Tuesday, 19 April 2016 15:02:28 UTC
Hello,

Never heard of NuGet Server and I guess you have shared a wonderful information about it

Thanks
Tuesday, 19 April 2016 18:56:23 UTC
Anxiously awaiting a docker image that does this...
Wednesday, 20 April 2016 05:47:01 UTC
If you're interested, I wanted to extend the same experience for delivering custom Visual Studio extensions that your team might develop. So taking the NuGet Gallery as a fork I added support for the custom Atom feed VS requires and flowed extensions from it. This means you could use your NuGet workflows when building extensions too 😊

http://www.inversionofcontrol.co.uk/hosting-visual-studio-extensions-on-a-private-nuget-gallery/
Wednesday, 20 April 2016 10:42:15 UTC
We started using Myget and so far we're happy with it - it's very easy to manage the packages including deleting a package or a particular version of a package, manage permissions, etc.
Wednesday, 20 April 2016 14:03:31 UTC
I've used both a directory-based and NuGet.Server
Pros and Cons of the directory-based:
Pros: You can set it up and have it running in seconds. LDAP-based security over the package repository.
Cons: Package indexing becomes extremely slow after packages start to pile on - roughly after 50.

Pros and Cons of the NuGet.Server:
Pros: a lot of control and high performance over every aspect of NuGet package hosting
Cons: When we used it, we were given a VM which was neglected (was shut down and not restarted automatically) and finally the VM became FUBAR so we had to opt out for the directory-based hosting.

Private NuGet feeds are a thing of beauty though - you can have digital content distribution for paying customers of your organization and its products.
Borislav
Thursday, 21 April 2016 03:00:45 UTC
I know that NuGet will look for the nuget.config in multiple places but does NuGet allow for an ordering of resolving depdendencies?


1) Look to a local folder (while developing) (pulled from %APPDATA%/Nuget/nuget.config)
2) Look to team NuGet server (From projects nuget.conf)
3) Look to public NuGet server (From projects nuget.confg)

Bert
Saturday, 30 April 2016 10:29:38 UTC
Nice article thanks for sharing this article with us.
Saturday, 30 April 2016 10:31:06 UTC
How Did you get an such idealistic information to express inn your postings.
Sunday, 01 May 2016 22:01:16 UTC
really nice article.i follow your website every day.thank you
Monday, 02 May 2016 06:01:22 UTC
We used VSTS nuget feed which works great. Only thing missing is having a private symbolserver.
Ankit Sinha
Monday, 02 May 2016 07:14:42 UTC
How did you get such a good information to post in your blog.
Monday, 02 May 2016 07:14:42 UTC
How did you get such a good information to post in your blog.
Monday, 02 May 2016 07:17:26 UTC
Nice and cool continue the postings.we are waiting for your posts to read.
Friday, 13 May 2016 13:17:07 UTC
To know the list of deep web links and what happens in the hidden internet.....
just click here ....Deep web links

Friday, 13 May 2016 13:19:36 UTC
To know the list of deep web links and what happens in the hidden internet.....
just click here ....Deep web links

Monday, 16 May 2016 16:53:06 UTC
I am currently evaluating Artifactory to host Nuget feeds.
Artifactory came from Java Maven world but began supporting Nuget in 2012.
Friday, 27 May 2016 22:41:48 UTC
I recently created a video tutorial on hosting your own nuget feed. Check it out here: Host your own local nuget feed note that this tutorial referes to the method of creating the server on a local or shared directory. Hoping to get some time soon to do another one on hosting the nuget server on an Azure web app.

Thanks for the great article Scott!

Chris
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.