Try as it might, Microsoft cannot provide every possible piece of code a developer could need. There are millions of developers on the .NET platform, each with unique problems to solve. It doesn't scale or make sense to wait on Microsoft to solve every problem.
The good news is that many developers don't wait around to “scratch their own itch.” They solve their own problems (and those of their peers) with useful libraries that they write and then distribute on the Web.
Three big challenges with all these libraries out there in the wild are discovery, installation, and maintenance. How do developers find a library in the first place? Once they find it, how do they make use of it in their projects? And once they've installed it, how do they track project updates?
This section walks through a quick example of the steps necessary to install ELMAH without the benefit of NuGet. ELMAH stands for Error Logging Module and Handler and is used to log and display unhandled exception information within a web application. The steps are especially familiar to the NuGet team because we use ELMAH in the NuGet.org site, which is discussed in Chapter 16.
These are the steps it takes to make use of the library:
All these steps for a library, ELMAH, that doesn't even have any dependencies! And if the library does have dependencies, every time you update the library, you need to find the correct version of each dependency and repeat each of the previous steps for each dependency. This is a painful set of tasks to undertake every time you are ready to deploy a new version of your application, which is why many teams just stick with old versions of their dependencies for a long time.
This is the pain that NuGet solves. NuGet automates all these common and tedious tasks for a package as well as its dependencies. It removes most of the challenges of incorporating a third-party open source library into a project's source tree. Of course, it is still up to the developer to use that library properly.