Should you use NuGet Package Restore on your Build Server?

In my opinion, no.

Recently, Mark Seemann wrote a terrific article regarding the dangers of using NuGet package restores on a build server. I highly recommend that you take a moment to read the whole article, but here are the major pros and cons that Mark offers to summarize the argument:

• The Package Restore feature solves these problems:
  • It saves a nickel per repository in storage costs.
  • It saves time when you clone a new repository, which you shouldn't be doing that often.
• On the other hand, it
  • adds complexity
  • makes it harder to use custom package sources
  • couples your ability to compile to having a network connection
  • makes it more difficult to copy a code base
  • makes it more difficult to set up your development environment
  • uses more bandwidth
  • leads to slower build times
  • just overall wastes your time

Having recently had this exact same debate at work I feel the need to chime in! I think that Mark's list really address the larger issue at core of this debate:

Do not add complexity for the sake of convention!

There are many best practices that can add additional complexity to project, but they always return value in other ways. Source control gives us secure change tracking, test runners ensure we have a functional product, build servers give us consistent deliverables, deployment systems offer reliable environment access.

What does NuGet package restore offer on a build server? As the aforementioned list of pros and cons points out, not much. I feel that it adds complexity without yielding any significant return on investment. As engineers it is not only our job to deliver efficient tools and solutions, but also to be as efficient as possible in our work as well.

So again, no, I do not recommend the use of NuGet package restore on your build server.

Just my two cents,
Tom