Reputation: 82547
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:
Am I doing this wrong? Or is NuGet not really meant for use with source control?
Upvotes: 14
Views: 7558
Reputation: 350
I must give a shout-out to this article: http://www.jsinh.in/2013/11/enable-nuget-package-restore/ It describes exactly what to do and why.
The notion of versioning various packages may be required for some systems to maintain build consistency, however, if the packages.config file is version controlled and the package can be downloaded, then the build can take place at any time without versioning the actual package contents themselves. Caution: The builder of the package, could without your knowledge, add items to an older build.
Rare, but possible.
For example, a package of 'abc.package' at version 2.0.2 is built into your project. You do not version the 'abc.package' but do version the packages.config. A few months later you need to add a bug-fix to the build you made a few months back. You get the items out of version control. Visual Studio downloads version 2.0.2 of 'abc.package', but since your last build, the developer of the package inserted or fixed some code. This new code may behave differently in your application.
So, there are good reasons to version control the packages!
Upvotes: 0
Reputation: 7133
Don't check the packages folder in.
Add the following prebuild event to your project:
$(SolutionDir)build\nuget install $(ProjectDir)packages.config -source \\server\path\NuGetPackages -o $(SolutionDir)packages
Omit -source parameter
if not using custom packages.
nuget.exe is checked into $(SolutionDir)build\nuget
.
Upvotes: 5
Reputation: 12396
I always check in just the packages.config folder and use a Rake task that the developer (and build server) can use to update packages locally.
The task looks like:
def nuget_for_project(project_dir)
sh "tools\\NuGet.exe " +
"i Source\\#{project_dir}\\packages.config " +
"-o Source\\Packages"
end
namespace :nuget do
desc "nuget for servicebus"
task "ServiceBus" do
nuget_for_project "SampleProject.ServiceBus"
end
desc "nuget for web"
task "Web" do
nuget_for_project "SampleProject.Web"
end
desc "nuget for all"
task "all" => ["nuget:ServiceBus", "nuget:Web"]
end
Note that the above script uses a local version of NuGet.exe that is in a tools folder checked into source control.
You could write this for MSBuild or NAnt instead.
I wrote a longer blog post on this a while back that may be helpful.
Upvotes: 1
Reputation: 427
Just in case this helps anyone, my solution to this was very simple:
This works for me on a solution with, at the time of this writing, 39 projects.
Upvotes: 0
Reputation: 119
I have this issue also. I like the idea of NuGet restore, but I don't feel I should need it. I want my JR developers to be able to check out a solution and have everything they need.
So I put my packages folder under source control.
My solution to enabling NuGet in this circumstance was to take note of this from above:
"I assume this is because the repositories.config file is now under source control (so it is read only until manually checked out)."
I opened the repositories.config file and added a blank line. Then I added the NuGet packages I need. Problem solved.
Upvotes: 1
Reputation: 14810
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:
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.
Upvotes: 11