NuGet – The Visual Studio Sweetner

Recently we saw some new features in Visual Studio 2012 for a Web Developer. One feature we didn’t touch upon was Nuget! NuGet per-se is not a new feature and it’s been around for a couple of years now. However, no Visual Studio article is complete without a mention of Nuget. So we decided to follow up with an article specially dedicated to NuGet .

This article has been co-authored by me and Suprotim Agarwal

I have been a NuGet user since the early days and I practically cannot write a blog sample without using Nuget. Fact is NuGet is so flexible that people have even written a deployment tool (Octopus Deploy) using Nuget.

Today we’ll see how we can leverage it from Visual Studio.

What is NuGet and why do we need it?

NuGet is what’s referred to as a package manager. It consists of a primary central repository of packages at Nuget.org and a Visual Studio extension to manage the packages.

If the word ‘package’ reminds you of COM packages fear not, we are not dealing with GUIDs and registry. A Nuget package is essentially a zip file with a XML manifest that defines the current package’s dependencies. The XML is reasonably easy to understand and CAN be handwritten. Packages referenced via Nuget are not added to the registry, instead they are local to a project and added at the root solution folder in the packages folder.

Here is what the packages folder for a newly created ASP.NET MVC4 application, looks like.

default-package

Believe it or not, there are actually 35 NuGet Packages used by the default ASP.NET MVC 4’s Internet Application template. If you look closely, you’ll see even MVC4 binaries are distributed and used as NuGet Packages.

In a nutshell, NuGet is a very clean and hassle free way of ‘adding references’ to your project.

Managing NuGet Packages

Let’s see how we can use NuGet Packages, but before that, let’s understand the Visual Studio integration and package management features.

In Visual Studio, you can add NuGet Packages using two UI entry points, the Library Package Manager or the Package Management Console.

The Library Package Manager

package-manager

The Library Package Manager dialog as shown above has a hierarchical group of packages on the left and a paginated list of available packages for the selected group in the middle. On selecting a particular package, it provides more information about the package on the right (like the Author, Version, Last Published, Description etc.

The three standard groups are

-    Installed Package: Selecting this category lists all the packages that the current project is using
-    Online: Packages that are available and can be downloaded from the package source
-    Updates: This lists any packages that are in use and have updates available on the server.

Launching the Library Package Manager
   
The Library Package Manager can be launched from two menu items.

First is the Tools > Library Package Manager > Manage NuGet Packages for Solution shortcut.

launch-package-manager-menu

Second is by right clicking on a Project or Solution from the Solution Explorer and selecting Manage NuGet Packages for Solution

enable-nuget-package-restore

The Package Manager Console

If you are more comfortable with a console type of an interface, you can use the Package Manager Console to install/uninstall/manage packages in a project

packge-management-console
   
Standard command for installing a package is

PM> install-package [name of package] <-ver x.x.x.x>

Where [name of package] is mandatory and the –ver flag specifying the version is optional. The –ver flag comes in handy to download and install pre-prelease version or older versions of packages.
The Package Manager is a tailored Power Shell environment inside Visual Studio.

Launching the Package Management Console

If you noticed above, the Package Management Console can be launched from “Tools > Library Package Manager > Package Management Console” menu item. Otherwise like all console windows it can be accessed from the View menu in Visual Studio. Specifically “View > Other Windows > Package Management Console”.

Local Package Management

NuGet's default package source is http://www.nuget.org. But NuGet manages a local cache of packages once you download them the first time. This saves bandwidth and time, the second time around.

However the Package Manager can be configured to use local or intranet package sources as well. To add these sources, all you have to do is go to Tools > Library Package Manager-> Package Manager Settings and select ‘Package Sources’

package-manager-source

To add a local source, simply click on the [+] button on top right, provide a name and set the source to a folder where all your .nupkg files are going to be, e.g.

add-local-package-source

You can select a shared folder location or an http URL too.

Each Package source you add, gets added to the ‘Online’ group in the Package Management Dialog.

Adding a NuGet Package to your Project

Now that we’ve seen how to manage NuGet Packages, let’s see how we can add and use one in our Project.

We have already created a MVC 4, Internet Project earlier. Let’s say we want to use the awesome SignalR library in our project. Let’s see how we can add references to SignalR.

Using Library Package Manager

1. Select Project in solution explorer, Right click and select ‘Manage NuGet Packages…’

2.  Select Online and in the ‘Search’ text box on top right.

3.  From the results that are returned, select ‘Microsoft ASP.NET SignalR’ and click Install. You get an ‘Installation Popup’ as the package gets downloaded and Installed
  
installation-progress

4.    It will show a License Confirmation Dialog, click ‘I Accept’ to continue or ‘I Decline’ to cancel.

package-agreement

5.    Once installation is complete, the Package Manager will show the installed dependencies as checked.

installation-complete
   
6.    There can be one variation to this sequence. If you have more than one project, once you select to Install a package, there will be an additional confirmation dialog asking you to select the projects to which the package should be installed.

Using the Package Manager Console

To use the Package Manager Console, simply open the console and type in the command
PM> install-package Microsoft.AspNet.SignalR

package-manager-console-auto-complete

As you can see above, you can get auto-completion also if you hit tab after partial package name.
Through the Package Manager Console you can install one project at a time (check the Default Project dropdown to see where the packages are going).

The packages.config

Next piece of the NuGet puzzle is the packages.config file. This file is a dictionary of all the packages installed including their versions. NuGet looks here to see if you have a package installed or not. If you remove an entry from this package (whether you remove it from the references or not), that particular reference is now gone from NuGet .

packages-config

Thus it’s very easy to remove a NuGet dependency or override it.

NuGet Package Restore

Final piece of the NuGet puzzle is the ‘NuGet Package Restore’ feature. Once this feature is enabled along with a privacy setting in Package Manager Settings, it works to download any missing Nuget packages before a build in Visual Studio. This is a super useful feature when you are using a remote source code repository and uploading multi-megabytes of dependencies in the packages folder is a time-constraint.

To Enable NuGet Package restore, you right click on the ‘Solution Name’ in the Solution Explorer and select ‘Enable Package Restore’ shortcut. This is a toggle option, so once it’s enable it changes.
Once you click ‘Enable Package Restore’, a solution folder called .NuGet is created and the Nuget.exe is placed in the folder.

You can check in this NuGet folder to your source control. Now when a team member downloads this from source control and try to build, they will get a warning as follows

missing-packages-warning

Clicking on Restore will update a Package Management Setting that will enable automatic downloads of Packages and also download the missing packages for this particular project.

Updating Packages

Components as we know, grow in functionality and newer, more stable version are released. So updates are always in order.

NuGet package manager make updates a breeze.

From the ‘Package Manager Console’ just use the command

PM> update-package [name of package]

..to update the package to the latest version. The update will upgrade dependencies if required. If upgrade of any required dependency fails, the update will be rolled back so that current references are not disturbed.

Using the NuGet Package Manager GUI, you will see available updates in the ‘Updates’ group. If there are any, you can select them and (like Install earlier) click on the Update button to get the latest version and its dependencies.

Conclusion

NuGet is a package manager for components used in application development using Visual Studio. The Nuget component repository is already pretty big and growing fast. It hosts most of Microsoft’s open source stack components and has fast become the favorite package distribution mechanism for open source projects.

We saw the various extension points provided in Visual Studio through which we can use NuGet and add package references to our projects. The ease of use is literally like the Sweetner in our Development IDE, that’s Visual Studio.

How to build your own NuGet package is a separate topic in itself and in future we hope to have comprehensive guidance on that too.




3 comments:

Anonymous said...

We use NuGet at work and it's working well. However I got a bit confused when it came time to update packages and dependencies. The process went by really fast but I saw some red text flash by like there was an error but couldn't see what it was and after it was done there was no error text so I thought it was ok.

Turns out only some files were updated because of the source control locking files. Since the update touches a lot of files in a lot of folders I wound up checking the entire project out and redoing the dependency update and then reverting unchanged files and it was fine. Seems a bit crude to do it like that. Anyone else having similar experiences?

Anonymous said...

Hi,

From my years of experience the best practice I follow when using Source control is to NOT check in the packages file AND enable Nuget package restore.

So updates impact only the packages.config file from a Source Control point of view.

Hope this helps,
Sumit.

Lamar Hays said...

It includes a major key database of offers at Nuget.org and a Visual Studio room expansion to manage the offers.