In a C# or VB.NET project, should we include the PACKAGE folder (NuGet package folder that is created in the root of my project that contains the nupkg files and other content) to our source control repository (Git for instance)?
-
Absolutely Yes, because these files are part of your code and your project won't build without them.– SharkyCommented Aug 4, 2016 at 7:16
-
I asked a similar question on SO along time ago. You can also look there for answers: stackoverflow.com/questions/1710027/… :)– cwapCommented Mar 10, 2017 at 7:49
-
I wonder why no one in Maven world ask "should we include 3rd party libs in version control". Find some solid counter-argument for NOT committing libs, though not very convincing.– Hoàng LongCommented Apr 23, 2019 at 10:47
4 Answers
A lot of time has passed, and NuGet has changed, so here's a new answer.
NuGet no longer creates a packages folder inside your source structure. Instead there is one in your user directory (%USERPROFILE%\.nuget\packages
on Windows, to be specific) where it puts all packages it downloads, and projects just reference these.
So the simple answer these days is no, you shouldn't. If you are worried about packages you need disappearing, you should create a local NuGet mirror that you back up separately.
-
7I'm on VS2015 (consider that VS2017 has been released just 3 days before you wrote this answer), and the package folder is present in my solution root. I'm curious about how and when NuGet has changed.– TeejayCommented May 2, 2017 at 21:29
-
18Just installed VS 2017 last week, created a new project yesterday and there is a package directory in my project.– JeremyCommented Jul 27, 2017 at 17:20
-
2What do you do for CI? do you make it Download all nuget packages again and again? (TBH: I, myself, am very unclear what my opinion is)– Tomer WCommented Oct 29, 2017 at 10:08
-
1There's nuances to nuget now. There's two different ways you reference nuget packages. For non-Core web applications, most of them use package.json, and these create a packages directory for the solution. "Package references" is the new way and its behavior is different.– AaronLSCommented Sep 12, 2019 at 22:17
-
1
It depends.
Check out Bart van Ingen Schenau's answer to determine if it's possible to ignore the packages
folder at all.
Basically: yes, NuGet is designed so that you can ignore the packages
folder and NuGet will pull everything from the Internet if it's missing.
But should you ignore it? I say: it depends.
IMO it's a question of "can we continue working in case the package repository is not available" (be it temporarily or permanently)
For my personal OSS projects, I have the packages
folder ignored in all of them.
When nuget.org is offline, I'll just wait and continue another day.
But it's something different at work.
Sure, you probably still have the packages locally on some machine, but is saving some space worth the hassle when your builds are breaking because your build server can't reach nuget.org?
We decided that space is cheap and we don't want the hassle, that's why we're committing the packages
folder to source control.
-
2
-
4Probably not very often. But maybe I should have said “unreachable” instead of “offline”. A few years ago, we had an incident at work where an excavator accidentally cut the internet cable to our building. Took more than a day to repair. If we had relied on nuget.org, we wouldn’t have been able to build our projects. (yes, I know, nowadays NuGet caches the packages locally...but not back then) Commented Jul 25, 2018 at 15:17
-
I will say build times are much longer when you don't checkin the packages folder because it spends most of the build time retrieving packages during package restore.– AaronLSCommented Sep 12, 2019 at 22:18
-
@AaronLS usually that part of the build time is insignificant compared to other parts of the build process. Most CI providers also allow you easily cache packages, so most of the time you'll be pulling from the cache rather than retrieving them as well Commented Feb 2, 2022 at 13:07
-
@ChristosDimitroulas Depends alot on project size versus size of dependencies. Compilation being a local operation tends to be faster, versus the remote operation of pulling down packages. In my experience the retrieval of the nuget packages is not negligible.– AaronLSCommented Feb 2, 2022 at 16:03
The basic rule for what goes into a source control repository is that you store there everything related to a project that you need to be able to build, test, deploy and execute the project and which can not be generated from items already present in the repository.
In other words, if you can throw away the PACKAGE folder and its contents without affecting your ability continue working on the project (the build might take longer, but you don't have to hunt down and install anything yourself), then the folder can be safely left out of the repository.
If the folder contains 3rd-party packages that might take a long time to download or that might become unavailable, then that might be a reason to add them to your repository anyway.
-
22I would add that you should keep a version of any 3rd party code used in the project stored safely, in case the 3rd party project is removed, the site hosting it is gone etc. A good place to do that is in your version control repository. That also gives you the opportunity to rollback to a previous version of that code, if needed.– BentCommented Nov 3, 2015 at 9:23
My stable datum is: "does it compile or not?"
So I created a VS2022 WinForm app on pc 1
I added a NuGet package NPGSQL v7.0
I compile ok and the app runs ok
I push to GIT without package folder
I clone my app on pc 2
I compile the app on pc 2 and compilation is ok
Package folder was created during compilation on pc 2
And the app on pc 2 runs ok
So I don't need to add the package folder to GIT
In your application root folder you should have a packages.config file if you have added NuGet package which lists all the packages which are used in your application so when you compile your application, the compiler will download all packages needed for your app with the correct version.