How to host your own NuGet Server and Package Feed
Hosting 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.
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.
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!
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.
About Newsletter
Philip Scott
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)
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.
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%).
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 ;)
For now, it's much easier to add the projects you need to your solution and use project references.
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!
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.
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).
Never heard of NuGet Server and I guess you have shared a wonderful information about it
Thanks
http://www.inversionofcontrol.co.uk/hosting-visual-studio-extensions-on-a-private-nuget-gallery/
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.
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)
just click here ....Deep web links
Comments are closed.