Today at work, I gave a presentation on NuGet. I’ve suggested they consider it as an option to ease management of the open source dependencies of our major application, so it was natural that I present the pros and cons.
NuGet is a system for managing .NET packages. It’s not unlike RubyGems or CPAN (for Ruby and Perl respectively), and while it has some work to do to be on par with those alternatives, they’re off to a very good start. Today’s presentation focused on just a few the capabilities of NuGet, and I’ll recap a few from my presentation in this post.
The primary use case for NuGet is the management of open source dependencies in a .NET application. There are a number of key open source libraries that .NET developers like me have been using in projects for years. Upgrades were always a pain because of having to manage their dependencies manually. Many of these tools (NHibernate, NUnit, log4net, and more) are already available as NuGet packages at the NuGet Gallery. I used NHibernate and NUnit in my examples today. Another tool that proved quite useful in my demo was the NuGet Package Explorer. Some of its features include:
- Opening and downloading packages from remote feeds
- Opening local packages to view and change their metadata and contents
- Creating new packages (instead of fiddling with XML manually)
In addition to getting packages from Microsoft’s official feed, it’s possible to create your own feed of NuGet packages. Phil Haack has a post on how to do this. My demo for work only included a local folder feed source, but I tried Haack’s instructions at home and they worked quite well.
I wrapped up my presentation with two different examples of building NuGet packages without a manually-created .nuspec file as a starting point. The documentation provides examples of how to generate a .nuspec file from an existing DLL, and how to generate a NuGet package from a .csproj or .vbproj file. I published the rules engine (which I found in an answer to a stackoverflow.com question), and a test assembly I created to the NuGet Gallery earlier this evening. If you want to check them out, just search for Arpc.RulesEngine in the NuGet Gallery. I still need to publish the rules engine source as a package and/or push it to a symbol server. Once the enterprise story for NuGet becomes a bit clearer, I hope I have an opportunity to present on that as well.
Just looking into NuGet myself. I’m particularly interested in managing in-house dependencies with it. I’ve seen a bunch of home-rolled solutions for this and it almost always becomes more painful than it should be.
I guess no one really wants to maintain the home-rolled tools.
At the time I presented on this topic, there wasn’t much of an in-house/enterprise story for using NuGet. Phil Haack’s piece in the latest MSDN Magazine doesn’t cover much in the way of new ground on that front either.
I think NuGet would be a great answer for in-house dependency management for some enterprises. I think it may take a larger company using it successfully *and* publicizing that fact before we see examples that we might draw from.
Beyond that, I hope to see more commercial tools vendors delivering their products and upgrades through NuGet. I think the delivery mechanism makes a lot of sense for vendors of controls like Telerik or Infragistics.