VS2010 - Package Restore always adds "packages" folder to TFS



we have solutions with enabled package restore. There is disableSourceControlIntegration set to true in nuget.config. But everytime someone gets the latest version from TFS and uses "Restore" button in Package Manager Console, this package folder is added to pending changes. Is there any bug in VS2010 console or why it happens? We have the latest console version (2.2.40116.9051). I think the same thing happens when I try to install a new package to project. When packages folder is created, it is always in pending changes.

Thnx for any help.
Closed Sep 4, 2013 at 6:08 PM by dotnetjunky
repositories.config is required to be present in the packages folder if you have multiple solution sharing the same packages folder. If you are not in that situation, you can go ahead and delete it. NuGet will restore it the next time you run it.


agilearchitect wrote Mar 19, 2013 at 11:46 AM

I confirm that VS2012 shows the same behavior.

Stif wrote Mar 21, 2013 at 2:30 PM

I can also confirm that we have the same issue with VS 2012 and TFS 2012. I also have the TFS power tools extension in my VS.
We have to be carefull when checking in to always explicitly exclude if the packages folder. And every once in a while somebody forgets that and we have to go and delete the package folder in tfs, so nearly of our project repositories now have a deleted packages folder in them.

Can anyone tell what the cause of this problem is? Or a possible workaround?

dotnetjunky wrote Mar 22, 2013 at 12:24 AM

I can't repro on VS 2012. Will try with VS 2010.

In the mean time, can you guys install the latest nightly build at http://build.nuget.org/NuGet.Tools.vsix and see if it still repros?

dotnetjunky wrote Mar 22, 2013 at 12:45 AM

I can't repro this bug in VS 2010 either. When I restore package, NuGet does add the repositories.config file inside the 'packages' folder to pending, but it doesn't add individual package folder.

Please verify if you check in, does individual package folder get checked in as well, or just the repositories.config file? The parent 'packages' folder may show an 'add' label, but that's just because of the repositories.config file.

RaptorCZ wrote Mar 22, 2013 at 6:25 AM

Wait, does it mean that root folder packages and repositories.config file are always added to source control? Only subfolders with packages are omitted? So it is missleading documenation for this, because I don't want to be this folder in source control. Whole folder. That's how I understand this feature.

It says: "The disableSourceControlIntegration setting instructs version control systems like TFS to not add the NuGet packages folder to the pending check-ins list." And it is not true. Whole packages folder AND repositories.config should be excluded ftom source control.

dotnetjunky wrote Mar 22, 2013 at 6:20 PM

Hmm, I just installed NuGet 2.1 to verify the behavior and it didn't add repositories.config file to pending. So I was wrong. This looks like a regression in 2.2. I'll fix it for this release.

Thanks for reporting.

dotnetjunky wrote Mar 22, 2013 at 6:30 PM

Actually no. :)

After checking the code, I realize that this was a design change we made in 2.2 to fix another bug. So yes, from 2.2, you're required to check in the repositories.config file. I'll update the doc to reflect this change.

Where did you read the documentation on this behavior?

dotnetjunky wrote Mar 22, 2013 at 6:30 PM

By design. From 2.2, users are required to check in packages\repositories.config file.

** Closed by dotnetjunky 03/22/2013 11:30AM

RaptorCZ wrote Mar 22, 2013 at 7:07 PM

That's pretty bad, because packages folder is never part of our solution and we have to check in "leftover files" without any solution relations.

Is there any way how to change this behavior to omit committing this file? Or why it was changed? Could you please share more info?


dotnetjunky wrote Mar 25, 2013 at 6:47 PM

Without the repositories.config file, we won't know which folder inside the packages corresponding to the a package that is being used by the solution.

What's the reason why you can't check in repositories.config and leave the other files under packages unchecked?

We'll consider moving repositories.config into .nuget folder to make it clear that this file needs to be checked in, but that won't happen any time soon.

RaptorCZ wrote Mar 26, 2013 at 7:03 AM

Ok, let's try another aproach.

How NuGet package restore works? Let's consider it is new solution and there are projects with NuGet packages. Every project's packages.config contains info about used package (id, version, framwork, etc.). This packages.config if checked in to TFS. That's OK. Because of a new solution, there is no packages directory in solution root.

Let's continue. When build starts, process checks all projets for packages.config files to get list of used packages, directory packages is created and inside is created a whole new packages.config. This one contains ONLY repository path items. Simply it is list of all project confings in solution. Nothing more.

So what now, I can delete whole packages directory anytime, because if it is not exists, it is simply recreated (directory + packages.config). Everytime. Right? So there is no need to preserve this in TFS. Everybody can delete this folder and it will be succesfully regenerated and corresponding nuget packages copied inside (from download cache, or downloaded).

You said: "Without the repositories.config file, we won't know which folder inside the packages corresponding to the a package that is being used by the solution. " I don't understand this. There are no information about folders or packages in solution. It is simply list of all existing packages.config files in all projects. Nothing more. No packages folder list, no names, no relations. Only list. You can call it cache or something. But still nuget process has to rescan projects before build and check if all projects are in packages.config.

And that's it. There is NO REASON to put whole packages folder to TFS. It can be created on build and preserve on user disk to speedup build process and nuget restoring. But it is NOT neccessary to check in this file. So I think this is a issue and it should be solved as bug, not closed as feature.

Thanks for understanding.

agilearchitect wrote Apr 2, 2013 at 12:25 PM

I agree with RaptorCZ that this issue should not be closed. Because the repositories.config file can be recreated locally I don't understand why it should be placed under source control. +1 to reopen the issue.

peter172sp wrote Apr 19, 2013 at 2:22 PM

Please reopen this issue. A file that can be recreated locally does not need to be under source control. It causes more problems than is solves.

dotnetjunky wrote Apr 19, 2013 at 2:55 PM

OK, I reopened it, but can you let me know what problems that it causes?

RaptorCZ wrote Apr 19, 2013 at 6:13 PM

Ok, please try to read whole thread again. Everything is here.

Short version - stop forcing users to add repositories.config to source control. There is no need to do it. For more info, please read my previous post. Thanx.

dotnetjunky wrote Apr 19, 2013 at 6:50 PM

I know that. But why is it casing more problems?

RaptorCZ wrote Apr 19, 2013 at 7:23 PM

So in other words, you just lied before instead of accepting issue, right?

You said: By design. From 2.2, users are required to check in packages\repositories.config file.

And now you know that there is no need to do it? Sorry, but you just confirmed this is a bug, so it is simple. Fix it, please. That's all.

dotnetjunky wrote Apr 19, 2013 at 8:32 PM

I'm not lying. You just don't read the text carefully. This is indeed by design. I intentionally want to check in repositories.config.

I reactivated the bug because you begged me to do so. That doesn't mean I confirm it's a bug. Although it's true that this file can be reconstructed on the fly, it means NuGet has to go through all projects in the solution. I may find a workaround that doesn't affect perf, or I may not.

RaptorCZ wrote Apr 19, 2013 at 9:19 PM

Ok, as you said, this file can be everytime recreated. But it takes some time. I understand. So how it works now (correct me, if I'm wrong):

1) Solution is opened
2) Nuget looks for packages\repositories.config
3) Nuget scans all projects in solution based on this file (because there is list of projects and packages.config files)
4) Nuget redownloads missing packages (based on packages.config) or force user to download them
5) Nuget checks if all existing packages.config are listed in repositories.config
6) Nuget saves modified packages\repositories.config (or creates a new one if this file is missing)
7) Nuget adds this file to pending changes

And that's it. Simply remove step 7. Nuget should create file, put it to packages directory and that's all. File will be there until someone removes it from disk. This file is not listed in solution, because package is not part of solution. It is standalone directory. File exists -> Nuget loads it. File does not exists -> nugget scans projects and creates this file.

Is it clear? I think this should work, or not? That's all I want. When disableSourceControlIntegration=false, don't add anything from packages folder to source control.

RaptorCZ wrote Jul 1, 2013 at 6:01 AM

Any answer?

robinsonpr wrote Jul 9, 2013 at 3:43 PM

I'm also interested in this issue.

I was under the impression that the whole packages folder along with repositories.config did NOT need to be committed to source control (I am also using TFS) once a solution has Package Restore enabled.

I've asked the developers on my team to be careful not to check in the packages folder (as TFS automatically wants to do so, we have to make sure we exclude that folder from the check-in list). But from reading the above particularly this comment: "I intentionally want to check in repositories.config", it sounds like I should let this config file go into source control?

It's not wanting me to check in any actual packages in the packages folder, just the repositories.config file. I don't see a problem with that.

dotnetjunky wrote Jul 9, 2013 at 11:49 PM

Yes, you only need to check in the repositories.config file under packages folder. NuGet won't add the package binaries when you enable package restore mode.

pmcevoy wrote Aug 19, 2013 at 9:40 AM

I'm keen to also remove the need to checkin the file.

Here's one reason not to check it in: We have multiple .sln files that live at the same source tree level - some with overlapping common projects (we reference by project rather than by assembly DLL to support Continuous Integration). We have multiple teams that work on the different solutions and different sets of nupkgs: a repositories.config that is generated by team A on web app A is not appropriate for team B working on web app B.

Constant edit churn on the repositories.config cause checkin conflicts that need to be resolved and in modest teams, this churn is a significant friction. We all know how hard it is to resolve merges on files that are managed/generated by VS.

Using TFS, We have needed to Deny all CheckIn permission on the packages folder to prevent this from happening

I can understand an optimization that speeds up builds after my first clean build - but as @RaptorCZ says, this optimization doesn't need to be checked in.

tfabraham wrote Aug 27, 2013 at 4:38 PM

With NuGet v2.7, we removed the .nuget folder and .targets imports from our solution and projects. The built-in package restore functionality in v2.7 now always adds the package binaries to TFS no matter what we do. We've tried checking in packages\repositories.config or no packages folder at all, and either way it tries to add the package folders to TFS.

Formerly we were relying on the disableSourceControlIntegration feature in NuGet.config with the old package restore functionality.

This is definitely going to cause developers to mistakenly check in the binaries, defeating the entire purpose of the new v2.7 restore feature.

stevozilik wrote Aug 30, 2013 at 5:34 PM

Whenever I'm updating existing packages it tries to add them to source control, even after setting the disableSourceControlIntegration="true" and checking the packages\repositories.config

Thanks to that, the update takes around 20 minutes, since VS is going through every single file and negotiating with TFS the changes!!!! This is a joke, do something about it

danliu wrote Aug 30, 2013 at 6:18 PM

@tfabraham, you can leave the .nugget\nugget.targets file in your solution, so that disableSourceControlIntegration can still be honored with the new package restore in 2.7.

here is a document for your reference - http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore.

could you please give it a try and see if that solves your issue? Thanks.