Reputation: 16841
What are the benefits for enabling the Nuget Package Restore feature in my Visual Studio solution?
The "Using NuGet without committing packages to source control" page in the Nuget Docs site suggests one reason:
When using a DVCS like Mercurial or Git, committing binaries can grow the repository size like crazy over time, making cloning more and more painful
Do you find this reason compelling enough to enable the feature? Are there other reasons?
Upvotes: 0
Views: 224
Reputation: 47967
There are more benefits of not having your NuGet package binaries in source control which are explained on another page, which I have reproduced here:
These benefits are still related to not having the NuGet packages in version control. So the reason you highlighted is still valid.
Also note that the "Enable package restore feature" which uses MSBuild based package restore has been deprecated by the NuGet Team in later versions of NuGet because it has problems with NuGet packages that include custom MSBuild targets. Instead the NuGet team recommend to not use it but instead use the Visual Studio based package restore which will restore NuGet packages just before you build the project inside Visual Studio.
Also when NuGet was first released the NuGet team at the time expected you to put the binaries in source control so you did not have to rely on NuGet when you wanted to build your project. So a developer could clone the repository and build the project straight away without having to use NuGet. However you now have a choice.
When you are working with a large version control repository, such as MonoDevelop, then including binaries can make the repository very large. For smaller repositories including the NuGet packages is not really a problem.
Upvotes: 3