This is Microsoft’s attempt to benefit from a large development community and pool of shared code, a concept enjoyed by many open source communities such as Drupal and Ruby on Rails.

The extension will manage the installation of libraries, files, references and any necessary configuration in the form of “packages” that can be added or removed.

NuGet is a free, open source developer focused package management system for the .NET platform intent on simplifying the process of incorporating third party libraries into a .NET application during development

With the Release of NuGet 1.2 the system has matured by allowing packages to specify the version of the .Net framework they are referencing types from, automatic binding redirects for the times where a package needs a different assembly version from the one that is currently being used as well as allowing the package to separate libraries for different platforms such as Windows Phone 7.

In this post I’ll step though how to install NuGet and utilize one of the many packages available. In a future post I’ll descript how to create your own package to share with the community.

Installing NuGet

NuGet runs on any commercial edition of Visual Studio 2010 or Visual Studio Express 2010 Visual Web Developer. Other express editions are not currently supported.
To install NuGet, open the Extension Manager in the tools menu in Visual Studio.

Click the Online Gallery on the left side, then type “NuGet” in the Search Online Gallery field.

Click the Download button on the NuGet Package Manager. After the installation you will need to restart Visual Studio

Using a package

After you’ve installed NuGet you have access to a library of hundreds of community developed packages. A gallery of which can be found here: http://nuget.org/

To install a package, right-click on the project you wish to add a package to and select “Add Library Package Reference…”, click “online” and search for the name of the package to use.

An example is the Fackbook.Helper package that makes it easy to add interactive Facebook controls. http://facebookhelper.codeplex.com/

Once you click install, the files included in the package are downloaded and automatically added to your project. A packages.config will also appear in your project and will display the packages used.

I have found however that in the case of some packages, not all the assemblies the package uses are added to the project’s references. In these cases I’ve had to manually add the references they need. Even then, sometimes not all the required assemblies are in the Global Assembly Cache (GAC). In these cases you should switch Copy Local in the referenced DLL’s properties to True so that the assembly is coped to your bin folder at build time.

Now once the Fackbook.Helper package is installed, I can easily add a facebook “like” button with the razor code:

@Facebook.LikeButton(URL to like)
@{
ViewBag.Title = "Home Page";
}

<h2>NuGet 1.2 Facebook.Helper Test</h2>
<p>
@Facebook.LikeButton("http://ghacks.net")

</p>

The result is a Facebook like button with precious little effort.

NuGet is in its relative infancy but already has over a thousand packages to explore. It is a welcome recognition by Microsoft of the strength of an open source community and the benefits for its developers.

New users should look at the Getting Started page and the Nuget documentation.

The terms ‘alpha’ and ‘beta’ have become muddied and confused over the years. Here is what these initial releases once meant:

Alpha Builds: Alpha releases where (and still are) largely internal builds used for evaluating the code. This stage of the product includes UI re-design, features being dropped in and out and lots of bug-fixing. Traditionally by the end of this stage the product would be code complete and usable.

Beta Releases: Either ‘closed’ or ‘open’. Beta builds were nearly feature complete and should be stable enough to be used. The point of a beta release wasn’t to discover any bugs in the software, but to discover bugs which the developers hadn’t yet discovered themselves through internal testing. Some of these are obscure and need wider testing.

Refresh Candidates: We see these less frequently these days, but a RC release is code complete. No new features will be introduced and all that’s left to do is find and fix the last few remaining bugs.

What these mean today:

These days I have no idea how exactly the development cycle works. Most developers seem to want to get usable software into users hands as soon as possible which is both good and bad.

ZDNet described this back in 2005 as:

Beta tests are getting longer, less restricted and more common, as companies tinker endlessly with their products in public.

The good is that many more bugs are picked up during the development cycle, user feedback can contribute to the project and it gives the software greater publicity then if they only tested internally.

The bad is that beta software can give a company or service a permanently muddied name. People expect beta software to be usable both performance and feature wise and anything which isn’t gets slammed. I have been guilty of this myself in the past.

When it comes to reviewing pre-release software, performance and stability should never be included as part of the review. Instead the focus should be on the possibility and promise of what the software is aiming to do.

I’ll try to remember this myself as I write and review products.