CODEWITHSUNDEEP
nugetsource-control-explorer
wonderful world
wonderful world

Reputation: 11599

Checking in the nuget packages

My app has few nuget package references. Should I check-in the packages folder also to the Source Control? My intention is to make the source code available to other developers and keep up with a stable version of references. I want to get a particular version of the depedable dlls from the Source Control for a date if I have updated the project with the latest nuget updates and the app breaks.

Or should I create a library folder and drop the dlls from the packages folder and check that in which I used to do before? And manage the packages folder local only?

Upvotes: 2

Views: 1677

Answers (2)

Matt Ward
Matt Ward

Reputation: 47917

You have to weigh the pros and cons of having the NuGet packages in source control or not and decide for yourself. The choice is entirely up to you.

I want to get a particular version of the dependable dlls from the Source Control for a date if I have updated the project with the latest nuget updates and the app breaks.

This is supported with either approach. If you do not check in the NuGet packages you should check in the packages.config file for each project. This file records the version of the NuGet packages used. So you could checkout an old version of your source code and it would be using the old version of the NuGet packages. NuGet packages on nuget.org are never deleted.

The NuGet site has documentation on the reasons you may not want to omit the packages from source control which I have quoted here:

Distributed version control systems (DCVS) include every version of every file within the repository, and binary files that are updated frequently can lead to significant repository bloat and more time required to clone the repository. With the packages included in the repository, team members may add references directly to package contents on disk rather than referencing packages through NuGet. It becomes harder to "clean" your solution of any unused package folders, as you need to ensure you don't delete any package folders still in use.

Problems with not checking the NuGet packages into source control can happen with build servers or with limited network connectivity. On the build server would you need to have access to the internet, or provide a local directory with the NuGet packages being used by the project. Also you would need to run NuGet.exe restore before the project is built or use the MSBuild based package restore (which has been deprecated by the NuGet Team). Note that if you are using a recent version of NuGet with Visual Studio then the NuGet packages are automatically restored when you build the project. Other IDEs have a similar feature or at least a way to restore the packages without having to use NuGet.exe from the command line.

The benefits of having the NuGet packages in source control is that you are not dependent on NuGet, other developers can take the source code and work with it without having to restore any NuGet packages.

Note that moving the dlls into a libraries folder means you are not getting the full benefit of NuGet. NuGet expects the dlls to be in the packages directory, all references are to the dlls in this directory, so moving the dlls into a libraries folder means you will not be able to use NuGet to update your projects.

The approaches to consider are:

  1. Check the packages directory into source control.
  2. Do not check the packages directory into source control and rely on NuGet restoring the packages.
  3. Do not use NuGet at all. Have the binaries in a separate directory which is checked into source control.

Upvotes: 3

siva.k
siva.k

Reputation: 1344

Because running the wrong version of a nuget package can horribly break your application I like to have them checked in even though it seems like a lot of bloat. In the long run it's done nothing but save my teams time.

Using the library folder also makes it non-trivial for someone to update a nuget package if the need arises. They need to remember to move it to this new libary folder and reference that.

It's worth remembering too that when you update a nuget package the old version remains in the packages folder, fyi.

Lastly using a tool like Nuget Restore may not work if you have automated build systems as they'll need the referenced DLLs included with the project and won't auto download them.

Upvotes: 2

Related Questions