NuGet is really nice. It’s almost magical. Just run a simple command and all kinds of packages can get added to your project. Template code files are added. Your web.config is modified in the right manner. You don’t even have to check them in to source control thanks to automatic package restore.
You can even create your own packages and make your own private packages sources.
But before we get carried away with this infatuation, let’s all remember that first loves rarely last. More than once I’ve been in the situation, that a build depended on NuGet packages residing on company internal NuGet repos. Work as a consultant on that project or hire a consultant to help? You get ccess to the source code, but still can’t build. Work from home? Forget it. Or how about simply working offline on a project with ONLY public NuGet packages? Use git to clean your work area and then rebuild. Sorry, git might allow you to work offline, but NuGet reintroduces that network connectivity dependecy, that we all thought we left behind, when we turned our backs to subversion, TFS or (the horror) SourceSafe.
There is also the question of code maintainability. The code that we write will have to be maintained (http://www.mit.edu/~xela/tao.html). You could easily have to maintain it 10 years into the future.
That is no problem of course, because NuGet will be here tomorrow as well, right? Well, there was a time that we thought ICQ was here to stay, later on Second Life was the future. Less than 10 years ago I worked in a company vastly dominant within its industry. We outright laughed when a certain fruit company made their first feeble attempts. Now, however, less than 10 years later, 50.000 employees have been layed off, everything that we thought was set in stone about how the market worked has been turned upside down. I see no reason to bet my professional reputation as someone who can maintain my code in the future on a dependency on some third party online package repository.
I’ve also been in projects where the continuous integration environment suddenly broke, because a bower package got removed by the developers behind it. “Well, you can’t remove NuGet packages once they are published!” Really? Maybe not today, but are you willing to bet that it doesn’t happen tomorrow?
Also, nuget.org doesn’t have a 100% uptime guarantee. It actually DOES go down every now and then. And then you can’t program for an undefined period of time due to circumstances beyond your control.
The solution to this problem is really simple. Check in your NuGet packages. Clean the /packages directory, build (so NuGet does the automatic package restore), check in whatever NuGet added to /packages and you are in the safe zone. NuGet restore will not attempt to go online as long as the /packages directory contains the packages you need.
This is not “best practice” you might say. I say “So what”?
The cost of adding /packages to source control is marginal at worst. There are NO downsides to it! What would you say if a colleague gave you access to a source code repo with all of his source files. Except one, which he insists on storing on a public OneDrive folder and restoring through a custom build step instead of checking it in?
So pretty please. With sugar on top. Check in your NuGet packages.