18

We currently don't use nuget for our dependencies, preferring to go old-skool way and stick them all in a libs folder and reference from there. I know. So 1990's.

Anyway, nuget has always made me feel a bit queasy... you know, reliance on the cloud and all that. As such, I'm find myself in the main agreeing with Mark Seeman (see here: http://blog.ploeh.dk/2014/01/29/nuget-package-restore-considered-harmful/) who says:

Personally, I always disable the feature and instead check in all packages in my repositories. This never gives me any problems.

Trouble is, this has changed in version 3, you can't store packages alongside the solution, as outlined here: https://oren.codes/2016/02/08/project-json-all-the-things/. Which sorta screws up checking them into source code.

So, am I worrying about nothing here? Should I drink from the nuget well, or side with Mr Seeman and er on the side of caution?

intinit
  • 480
  • 4
  • 14
  • Personally, I would never store the packages in source control. They're stored in Nuget for a reason, why would you want to clog your git repo up with specific versions? When you upgrade, do your devs clean up the local copies? Nope. Or at least, unlikely. If you use the latest nuget paradigm, packages will automatically restore, if they're not found. You can also weave this into a command line option with `nuget restore xxxx.sln` – SpaceBison Mar 04 '16 at 16:17
  • 1
    If your main concern is access to the nuget.org repo (connectivity) then set up a private nuget server to cache the packages you need. This could be a file share or a free nuget server (the nuget.org repo is OSS) – James Reed Mar 05 '16 at 22:56
  • Possible duplicate of [Can (Should) I put 3rd party libraries in version control?](https://stackoverflow.com/questions/1710027/can-should-i-put-3rd-party-libraries-in-version-control) – CJBS Dec 26 '17 at 19:09
  • Related: https://stackoverflow.com/questions/1710027/can-should-i-put-3rd-party-libraries-in-version-control – CJBS Dec 26 '17 at 19:12
  • Also related, with arguments in favor of including in source control: https://softwareengineering.stackexchange.com/questions/301547/should-we-include-nuget-package-folder-in-version-control – CJBS Dec 26 '17 at 19:13

2 Answers2

16

Storing NuGet packages in source control is a really, really bad idea. I accidentally did it once and I ended up bloating my source code considerably, and that was before .NET Core...

Drink deep from the NuGet well. Most software components are packaged in a similar way these days (NPM, Bower etc). The referenced blog post is two years old and package management is changing rapidly in the .NET world, so here's some of my experience lately.

  • NuGet packages can't be deleted from nuget.org. They can be hidden, but if your application requests a hidden package it will download it as normal. It'll never disappear into the void.
  • 'Enable Package Restore' is no longer glitchy because it's now a default option in NuGet 2.7+. You have no choice anymore.
  • Packages are no longer stored per solution but per machine, which will save a ton of bandwidth and will decrease the initial fetch period when building.
  • If you build a new project using .NET Core, you will have dozens more packages as the entire BCL will be available as NuGet packages. Do you really want to check-in all the System.* packages into source code?
Damien Dennehy
  • 3,937
  • 2
  • 19
  • 21
  • 6
    > "NuGet packages can't be deleted from nuget.org." - this is untrue. The `Microsoft.Net.Compilers 2.0.0` package was published prematurely and some of my projects automatically updated to it, then the package was pulled from NuGet and I couldn't build my solution at all and NuGet complained about being unable to download it. I had to manally tweak my `packages.config` and `csproj` files to reference `1.3.2`. See here: https://github.com/dotnet/roslyn/issues/14591 – Dai Mar 10 '17 at 01:15
  • 1
    Just to say, we went with the nuget and version 3 is so much better than version 2. We've never had any issues, it works great at the solution level. It is the way to go, mind you, I don't turn on automatic updates. – intinit Apr 04 '17 at 07:55
  • I just verified that if you just archive file `[project]/packages` and update another checkout of your project, VisualStudio build process will also run `bower/npm update` which pulls the required packages from NuGet. Really no need to archive the packages themselves. Great. – Roland Nov 05 '19 at 16:59
1

There is a very simple reason why you want to store Nuget packages in source control. Your organization doesn't want your build server to have internet access.

Bob
  • 31
  • 2
  • We’re in a similar situation. We have a private NuGet repo that everything internally can access, except for a single Azure DevOps pipeline that builds a Xamarin app for iOS. Such a pain. It’s a special unicorn. – br3nt Sep 03 '22 at 02:59