Ever hear the phrase, “Don’t reinvent the wheel?” That little phrase is one of several principles that guide writing good code. Given the vast richness of the .NET Framework, I’ve learned this lesson many times over. I can’t even count how many times I’ve written what I thought was great piece of code only to show it to someone and then be told, “You know the .NET Framework provides that already, right?” Doh.
In the Ruby programming world, one of the ways they avoid reinventing the wheel is with a “package manager” called RubyGems; in the PHP world they use Composer, and in the Node.JS world they use NPM. These package managers let programmers download, install, and configure open source components on a per-application basis. They are very popular—especially Ruby Gems—it has had more than a billion(!) downloads. NPM (the new kid on the block) had 9 million downloads last month. Package managers make it a breeze to add open source components to programs. You download them from the Web and they install, and configure, themselves into your application very gracefully. They are also able to install necessary dependencies. In short, they take the frustration out of using superb open source software for these programming communities.
There have been open source projects for .NET for many years. However, the lack of a cohesive .NET package manager has made them essentially the domain of uber .NET nerds for many years. In the past, to use .NET open source software, you first had to know about it (with Twitter or Podcasts usually), then you had to download it, then you had to manually install and configure it, and then carefully read its instructions for other dependencies. For all but the dedicated, it was often more work that it was worth.
Microsoft’s first serious outreach to the open source community was when it embraced jQuery, the very popular JavaScript library. In the early days, some were worried that MS embraced jQuery only for devious reasons. Some thought MS intended to bait and switch jQuery with something else brewed in-house; others thought MS was going to MS-ize jQuery to the point that its loyal followers would retch and gag at the thought of using jQuery. Alas, none of these negative things have happened. MS continues to distribute a non-sullied jQuery with Visual Studio and nearly every programmer applauds the move now. MS’s reasoning for adopting jQuery was simple: why reinvent the wheel when there was such an overwhelming open source alternative available. (The cynic in me also wants to point that MS didn’t exactly set the world on fire with the overwrought and ineffective JavaScript libraries of its own.)
jQuery adoption was just the tip of the iceberg and MS did, finally, see the value of actively embracing open source software. A couple of years ago it introduced NuGet (say “new-get”), a package manager for Visual Studio. NuGet now has more than 9100 total unique packages and has had nearly 35 million downloads since its inception. You install NuGet from its Website (shown Figure 1) and then invoke NuGet with the context menu (from the Solution Explorer) shown in Figure 2. Figure 3 shows NuGet’s interactive UI as displayed in Visual Studio—this is where you select components for installation and automatic configuration.
Figure 1. nuget.org Website.
Figure 2. NuGet’s on the Solution Explorer’s context menu.
Figure 3. Nuget’s interactive UI from within Visual Studio.
Don’t confuse NuGet with Microsoft’s Web Platform Installer (Web PI). NuGet installs components at the solution or project level (depending on the component). For example, when you use NuGet to install the JSON serializer JSON.NET, it installs it into a specific project. Web PI, on the other hand, installs software at the machine level. For example, you use Web PI to install IIS Express on your machine for all of your apps to use. Although NuGet packages aren’t aimed specifically at AVR for .NET, I have used many NuGet packages with AVR and all worked very well.
The open source community offers a vast array of superb solutions to many of your software challenges. If you aren’t using NuGet today to discover the solutions that await you, get busy with NuGet now. Otherwise, you are reinventing the wheel!
