Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Multiperson team using NuGet and source control

I am on a two-man team using Team Foundation Server for our source control. I started a new solution. For that solution I created several projects. In many of them I used NuGet to install AutoMapper and Unity. I then right clicked on the solution and selected "Add to Source Control". I then checked in the resulting pending changes.

The other person on my team did a get latest and all of the NuGet references are failing for him.

So, I figured I needed to add the packages folder. So I did that.

After I did that, the NuGet references are still failing (for him).

Also, when I try to add a NuGet Package to a file I get this error now:

Access to the path 'C:\src\MyPath\ToMySolution\packages\repositories.config' is denied.

I assume this is because the repositories.config file is now under source control (so it is read only until manually checked out).

So, here are my two questions:

  1. How or what do I check in so that the NuGet packages are valid for my coworker when he does a get latest?
  2. Is there a way to not have to manually check out the NuGet files when I need to use NuGet?

Am I doing this wrong? Or is NuGet not really meant for use with source control?

like image 641
Vaccano Avatar asked Aug 10 '11 17:08

Vaccano


People also ask

Should packages folder be in Source Control?

Should I check in the Packages folder in the Source Control to make them available for peers? The answer is "NO". You should not checkin packages folders since this will increase the size of the repository and it will become overhead when taking the latest (since the size of the packages folder is in the MBs).

What is NuGet used for?

NuGet provides the tools developers need for creating, publishing, and consuming packages. Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.

Should you commit NuGet packages?

NuGet now has the ability for you to re-download the missing packages as a pre-build step, meaning that you only need to commit your packages. config file (and include nuget.exe in a tools folder). Read Using NuGet Without Committing Packages to Source Control for more details.


1 Answers

Edit 2014/03/31: The manual MSBuild-based package restore enablement is no longer needed, see also http://xavierdecoster.com/migrate-away-from-msbuild-based-nuget-package-restore.

Edit 2012/02/07: This is now a built-in feature of the NuGet vsix, called Enable Package Restore.

Obsolete Alternative

There is a NuGet package for that, it's called NuGetPowerTools. It adds two new commands to the NuGet Package Manager Console in Visual Studio, amongst which Enable-PackageRestore is the interesting one for you.

It will add a .nuget folder which contains nuget.exe, nuget.settings.targets and nuget.targets. When you run enable package restore, it will enumerate all projects in your solution and add an import nuget.targets statement in the project files (which are actually msbuild files themselves).

Whenever you build a project or the entire solution, nuget will fetch all packages for that project/solution, as defined in the packages.config file. This happens in a pre-build step.

So, in short:

  1. do not check-in packages
  2. do check-in the config files (repositories.config and packages.config files)
  3. use Enable Package Restore
  4. check-in the .nuget folder

Whenever someone gets the sources, whether that's another developer in the team or a build agent, the msbuild process will be instructed to fetch any required packages in a pre-build step.

Also, when the packages are not committed into TFS Source Control, you won't hit the read-only flag issues, or merge conflicts with binary files.

If you want, you can also check-out the underlaying reasoning for this approach on my blog.

like image 112
Xavier Decoster Avatar answered Sep 19 '22 05:09

Xavier Decoster