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!