NuGet PackageRestore is awesome

It’s safe to say I’m a NuGet fan.  I’ve been using and following NuGet since the original Nubular days, but somehow I missed the significance of the Package Restore feature announced in version 1.7. I’ve had a chance to try it out. Simply put, it’s awesome.

Package Restore is a feature that allows your project to download and install packages as they’re needed, which means you don’t have to commit these packages into your source control repository. Java developers will recognize this feature as something similar to Maven, which has been around for while, but for .NET this is a very welcome change.

Enabling the feature in Visual Studio is pretty simple, just bring up a context-menu on the Solution Explorer and choose “Enable Package Restore”. Once enabled developers (and your build server) don’t even need to have NuGet installed to take advantage of this, they simply need an environment variable “EnableNuGetPackageRestore” defined.

The impact this feature has on your development team is subtle, but very powerful, and after using it on my current project I’m realizing how crippling our previous approach has been.

Up to this point my usage of NuGet has focused around the initial stages of the project, when the solution and dependencies are initially being put together. In this scenario, I’m checking the packages NuGet installs into my source control which means other developers (and my build server) have everything they need to compile the solution after they’ve got the latest source from the server.

Checking libraries into source control exposes a few interesting, and a bit too common, pain points:

• Upgrading packages isn’t easy because developers may manage the dependencies for projects manually, even if they have NuGet installed. In a way, I can’t blame the developers for doing this because this is, after all, how we’ve been managing our dependencies for years. But ultimately this practice defeats the purpose of using NuGet in the first place: I can’t upgrade all my projects in my solution to a newer version of the package if there are projects that NuGet isn’t aware of.
• Source control can get bloated with different versions of packages over time. If developers are using NuGet to manage their packages, they might forget to remove old versions in the repository. It takes a bit of extra discipline to stay on top of this.
  • Side note: depending on the connection between your build agent and server this bloat is potentially slowing down your build.
• Developers can still experience problems where their Local workspace isn’t current. This problem happens fairly frequently, if a developer isn’t getting the latest copy of the packages folder on a regular basis.

Over the past few weeks, I’ve found the package restore feature addresses these concerns, plus a few extra perks:

• We’re more open to trying out new packages because there’s less operational overhead. Developers don’t have to worry about breaking the build because they forgot to check in required assemblies, and the impact to remove the dependency is limited to the project file and config file. Less operational overhead makes the team more flexible to change when necessary.
• There’s new found desire to move existing dependencies to NuGet packages. NuGet has helped our team visualize the relationship between our dependencies which plays into how we’ll update and manage our packages, but it also automates the dependency management. For example, the process of duplicating a project’s dependencies when setting up a test project is greatly simplified. Once these benefits are realized, you’ll being to scrutinize the dependencies in the solution that aren’t managed by NuGet. In some cases, this has led us to create packages for our reusable libraries – which is so awesome because this will benefit our project and the organization as a whole. And that’s cool.

So there you have it. If you’re not using NuGet, you should download it and give it a try. If you’re already using it but not leveraging Package Restore I challenge you to give it a spin – does it make your team productive? Leave a comment below!

Happy coding.