Remember the notorious DLL Hell problem? About a decade ago, before the advent of the .NET platform, most applications were based on dynamic-link libraries, and multiple apps often shared DLLs.
At that time, DLLs were identified primarily by name, and version info often wasn't recorded properly. If a new application inadvertently replaced a shared DLL component, other apps that used that component would break. The solution to this problem came with the .NET platform and Global Assembly Cache, which gives registered components strong names that contain details such as version and author information.
With this problem solved, developers now are grappling with a new one: the third-party DLL Hell.
In the beginning of the .NET era, applications used only a few commercial third-party libraries, mostly for user interface needs. The number of these components per application was low, and managers knew which ones they were because they had to pay for them.
Today, there are many more high-quality, third-party components available. In addition to top commercial suites of user interface controls, you'll find quite a few well done, free, open-source libraries.
Increasingly, .NET software projects are based on a variety of third-party components. On average, a project can use six or seven of them. For example, an ASP.NET MVC project may have an IoC framework, a mocking library, ELMAH or something similar for error handling, perhaps the Microsoft Enterprise Library, DotNetOpenAuth for authentication against social networks, NHibernate or some Entity Framework extensions, jQuery and friends, maybe some other facilities for mobile and HTML 5 views and client side validation...the list goes on and on.
There are two problems with third-party components. Companies must ensure that developers only use an approved set of libraries. And developers face the problem of repeatedly going through the same (often cumbersome) configuration procedure for a given library a frustrating and time-consuming operation.
Referencing some of these third-party components isn't as easy as referencing an assembly. More often than not, you must first download binaries to the development machine, and then browse your hard disk in order to reference them in the new project. Sometimes, you must repeat the operation for multiple assemblies. And sometimes you also have to enter changes in the configuration file of the .NET application and add ad hoc source files to the project. With few exceptions, referencing a third-party component is painful.
The NuGet Solution
NuGet is free package-manager application aimed at making it easier for developers to reference third-party libraries from within a Visual Studio project. NuGet provides a command line and GUI frontend, so packages can be quickly installed and uninstalled. It acts as a host for uploaded packages and lets developers discover them by name and tag-based searches.
Integrated in Visual Studio 2010, NuGet lets developers reference a commonly used third-party library with one click. You open the package manager, scroll the list of available packages, pick the one you're looking for, accept the license agreement (set by the package author, not Microsoft), and download.
Each NuGet package contains files (sources, data, help, and binaries) to be added to the Visual Studio project and instructions for the manager. Once the download is complete, the package manager copies the files and sets up the project as appropriate. This means, for example, that assemblies in the package are added to the list of existing project references and changes required to the configuration file are merged with the current configuration file.
In a couple clicks, you're set. NuGet definitely saves time.
Vibrant .NET Community
According to Phil Haack, one of the NuGet architects, its primary goal is to foster a vibrant .NET open-source community by simplifying the way in which .NET developers share and use open-source libraries.
In this regard, NuGet was a great success. Launched less than a year ago, it's one of the most compelling open-source projects. A large and growing number of .NET developers use it, and just the fact that adding a dependency is so easy represents a good reason to add more third-party componenents and libraries. (I think this is similar to what happened in the '90s with Visual Basic and VBX components.)
Companies often put strict boundaries around which frameworks and libraries their developers can use, and they often designate a select group of people to approve the third-party components that can be used. Open access to NuGet's repository doesn't necessarily break these policies.
NuGet package managers read the feed of available libraries from a location on a Microsoft website where developers can upload custom packages for others to use. And, unlike the Apple Store and Windows Phone 7 marketplaces, there's no approval workflow for submitted packages.
NuGet can be configured to point to a shared folder on an intranet, letting a company have its own local NuGet installation. Developers enjoy the benefits of NuGet, while managers ensure that developers access only an approved set of libraries. In addition, organizations no longer need to produce internal documentation on how to locate and install approved libraries.