Re-Introducing NuGet (and introducing Chocolatey)

Last month, I presented on the topics of NuGet and Chocolatey at RockNUG as the lead-in to David Makogon’s Polyglot Persistence talk. Since the time I first gave a presentation on NuGet at a previous employer a couple years ago, the package manager has matured quite a bit. Because there was far more than 30 minutes worth of material to discuss, the rest of this post will cover material I didn’t get to, commentary from the audience, and the answer to a question about tags.

In discussing the term package manager, I indicated that it meant more than one thing:

  • automation of dependency management for operating systems (think Unix or Linux distributions)
  • automation of dependency management for programming languages (think Perl's CPAN, Ruby Gems, Node.js npm)
NuGet is the second type.  I find Chocolatey quite interesting because it's a package manager of the first type that leverages the capabilities of NuGet to accomplish its work.

NuGet enables us as developers to define and re-define what a third-party dependency is.  The team at Fortigent (one of RockNUG’s sponsors) has made packages out of some of the functionality they’ve developed internally.

There are a couple of different ways to create packages:

The second way is recommended for integration with build systems.  Typing "nuget spec" in the location of the csproj file you want to make a package out of will generate a "nuspec" file (in addition to automatically referencing other files as dependencies).  Edit this file in order to add tags, licensing, links and other information you want to make available in your package.  Typing "nuget pack" followed by the csproj file will generate a file with the .nupkg extension.  The extension merely hides the fact that it's a ZIP file with some additional information.

In addition to creating packages, NuGet gives us the ability to set up our own package feeds.  The feed can be a simple as a network share with packages in it.  One step up from that is to create an empty ASP.NET Web application and add NuGet.Server to it.  This will add everything to the application needed to host your own packages (or others from third parties).  You can even publish your packages to this type of application if you wish.  The pinnacle of NuGet package distribution is to host your own fork of the NuGet Gallery (available on GitHub).  One software vendor, JetBrains, forked the NuGet Gallery to publish documentation on all the plug-ins available for the latest version of ReSharper as well as make it possible to download ReSharper itself.  Chocolatey uses the NuGet Gallery code in a similar way.  Unlike the ReSharper gallery (which doesn’t let you download plugins), the Chocolatey gallery does allow it (though the actual installs require command-line interaction, which is helpfully displayed next to each package).

One of the NuGet-related projects I found particularly interesting is concierge.nuget.org.  Its objective is to recommend NuGet packages in the same way we receive movie, music and product recommendations from Netflix, Spotify or Amazon.  Simply upload the packages.config file for your project and get recommendations back.  I learned about this (and other .NET development-related topics) on The Morning Brew.

Q & A

While there weren’t any questions at the end, there was one asked during the presentation about the “tags” element of the nuspec file inside each package.  When you look at a package in the NuGet Gallery (like EntityFramework for example), you see a list of linkable tags.  Clicking on one actually triggers a search for each package that shares a particular tag.  So if  you’re a package author who wants their package to be discovered more easily, putting the right keywords in the “tags” element will help.