This project is read-only.

Allow repositories.config to be moved


It's currently placed in $(SolutionDir)\Packages\ , which is not a bad place per se, but if you don't want to check that folder into your source control, it's a problem.

A trivial work-around would be to search for it in $(SolutionDir) if it's not found in the Packages folder. That would permit it to be moved up a level and the source control repository can remain blissfully unaware of the packages folder.


TDietrich513 wrote Jun 27, 2011 at 7:39 PM

Another possibility, if repositories.config is not found, rebuild it by looking for a packages.config in each project folder.

dfowler wrote Aug 4, 2011 at 8:03 AM

We're just going to move it.

robblovell wrote Jan 4, 2012 at 4:13 PM

This is a real problem for us. First, where is the documentation on what this is? Second, it has completely screwed up our workflow by suddenly appearing when one of our packages is added as a reference. We expected that the package restore module would have no problem bringing in this package. We don't check in packages and we use package restore. The workflow is to NOT check in the packages directory.

The work around I guess is to rename the package restore directory and check in the packages directory, but that doesn't solve the problem of why it's occurring in the first place? Package restore already knows the location of the packages.config in its configuration file and repositories.config is completely unnecessary.

On another point, the name repositories.config implies that there is a repository there with nuget packages, not a list of dependencies. So the name itself doesn't imply why it's there.

So my question remains WHY? Where is the documentation? What is the use case for this?

XavierDecoster wrote Jan 4, 2012 at 5:28 PM

Would be cool if:
-repositories.config is moved to $(SolutionDir) level
-Enable-PackageRestore did this as well (to progressively move this file to the new location as people upgrade NuGet in the future)
-If not found, NuGet searched for it in the $(SolutionDir)\packages folder as a fallback <-- this is even enabling backwards-compatibility, allowing people to upgrade to a new version of NuGet without being forced to fix their source control layout

robblovell wrote Jan 4, 2012 at 10:56 PM

After more investigation, it appears that since we don't check in the "packages" folder the "repositories.config" file was eventually deleted. while package restore continued to allow the projects to be built, once development continued on and more references needed to be added via nuget, references got lost by nuget setting up a synchronization problem between the package restore script and the nuget package manager.

The VS thinks there is only one additional reference, where as the package restore knows about all the old references, but not the new ones. It will bring in all the old references, but leave out any that have been added. New references will have to be manually modified.

I am exploring a workflow that involves re-issuing the package restore install and enable.

duluca wrote Feb 28, 2012 at 9:39 PM

I'm having a package restore problem, where several projects are being shared across multiple projects (as externals in SVN). I don't check-in packages, but nuget restores the packages relative to the solution file, the project is expecting to find the package relative to its original solution.
Any ideas to work around this?

drewmiller wrote Feb 28, 2012 at 10:29 PM

@duluca Package restore wasn't designed to be used with things like SVN externals or git modules; it expects the projects to be consistently relative to the solution. I don't know of any work-around off-hand.

diegohb wrote Oct 15, 2012 at 7:45 PM

Is there any plans to make the repositories.config file be solution-specific (reside next to the sln file) so it's a list of packages for each solution as opposed to a listing of all packages in a given packages root folder.

I use a common repository root folder for all of my solution and so because of the repositories.config there when I do Manage Nuget Packages for Solution in VS, and look at Installed Packages, it shows me many more packages than just the ones installed on my solution.

MisterJames wrote Feb 18, 2013 at 7:32 PM

Just wanted to add my voice here...VS2012 is crashing on solution load with the latest bits. I'm seeing this on Win7 and Win8 when downloading from the repository.

It seems our only workaround to not check the packages folder in is to manually exclude each package as we add it to multi-project solutions. Which is, erm, not so fun.

kfrajtak wrote Jun 15, 2013 at 12:09 PM

I came up with code changes for using solution level repositories.config file (with minimal code changes)