If you’re working with ASP.NET and haven’t made the jump to MVC yet, you have to admit it’s getting harder and harder to not commit. We’ve got some pretty juicy tools on this side of the fence with MVC3, especially when coupled with NuGet and some of the 1600+ Open Source packages that are already available free of charge.

Installation, Adding, and Upgrading Packages

When you use an “Install-Package” command to install a package, NuGet runs offers to grab the latest version of the package from the repository. It “installs” it in the packages folder under your solution:

It adds entries to your packages.config file in your target project:

It may modify your web.config files…

…add project references…

…or files…

…before completing. And if there are other dependencies in the package, those are downloaded and installed as well. You will be notified if there are any conflicts.

Updating is a little more tricky because there is no auto-resolution from the console to force all the required dependencies to upgrade. To see what I mean, try installing Ie9ify to a new MVC3 project. You have to go through:

an error and rollback on the ie9ify package install…it’s requesting jQuery 1.5.2
you attempt to update jQuery, but it fails because of dependencies
you have to update each package separately (jQuery UI, Validation, and vsdoc)
then you update jQuery
then you can install ie9ify

Now you can pass in a –IgnoreDependencies flag, but that doesn’t really help get you out of the water; you’ll still need to update all the other packages and resolve the conflicts manually.

Multiple Projects

Note that if you have more than one project on a solution that NuGet has to have a target for where its action will play out, and I’ve found that this will be the first project added to the solution. So, for example, if you create a blank solution, add a models project, and then add an MVC project, you’ll need to retarget your Package Manager Console.

So, not always a necessity, but worth looking at if a package install/update goes south. You will notice this blatantly if you try to update or uninstall a package when you are targeting the wrong project.

There are legitimate reasons to target different projects at different times, so this is a great feature to have. It is confusing, however, to have NuGet auto-complete package names for you when you try to tab them out; all packages installed in the solution will appear in the list.

Cleaning Up Post-Uninstall

Actually, I’m surprised at how good a job NuGet does at cleaning up. For instance, if the package adds entries to the project’s app.config or web.config files, it will properly remove them for you as well. Same goes if it adds files to your project; they, too, will be removed. Binary references, same deal.

There are some instances where an uninstall will report a clean job, but you’ll still need to do a little work. Here are a few examples:

If you rename a file that’s been added by a package, it will remain in your project.
You can change the value component of web.config and app.config files and NuGet will still remove them cleanly, but if you change the name/key of the entry, it’ll stick around.
Dependencies aren’t removed when you remove a package, even if they are installed with the package in the first place.

Rounding Up

While there is still some room to grow, NuGet has become quite the little workhorse in the last few builds. With the power of Power Shell behind the scenes, most third party integration can be automated by package contributors. Not only is there a growing library of community-sourced packages out there, but you create your own as well, or even create your own repository internally and take advantage of easy project setup company wide.

Questions about NuGet? Just ask! I’d be happy to help work through anything you’re trying to tackle.

Real World Scenarios Working with NuGet