Removing repositories.config file

Topics: Ecosystem
Mar 25, 2013 at 12:22 PM
In our projects we have an "enterprise" requirements that NuGet in current state does not meet:
  • we would like to have a shared location where the packages will be stored
  • libraries will be referenced from this directory using absolute path
  • there won't be conflicts when one solution with packages will reference (as project reference) another project with packages
I don't fully understand the role of repositories.config file placed under packages directory. I looked into the source code and implemented a class deriving from SharedPackageRepository class. I got the idea that the list of .packages files can be discovered by searching for the items in all projects in solution.
public override IEnumerable<string> GetRepositoryPaths()
  // not using <repository path="..\packages.config" />
  // get the solution
  var solutionManager = ServiceLocator.GetInstance<ISolutionManager>();
  var tempPaths = new List<string>();

  const string fileName = "packages.config";
  foreach (var project in solutionManager.GetProjects())
    var projectItem = project.FindProjectItem(fileName);
    if(projectItem == null)

    var directoryName = Path.GetDirectoryName(project.FileName);
    if (directoryName == null)

    tempPaths.Add(Path.Combine(directoryName, fileName));

  // Paths have to be relative to the this repository           
  var paths = new HashSet<string>();
  foreach (var tempPath in tempPaths)
    string path = NormalizePath(tempPath);

    if (String.IsNullOrEmpty(path) || !FileSystem.FileExists(path))

 return paths;
To implement this I have to change the SharedPackageRepository (making some methods virtual) and add this file to VisualStudio project (thanks to use of ISolutionManager).

Can anyone tell me if this is a good idea or not. Thanks.
Mar 25, 2013 at 3:24 PM
kfrajtak wrote:
Can anyone tell me if this is a good idea or not. Thanks.
Strong not.

These requirements are bizarre, and sound like a workaround for a misunderstood problem. I've worked with a lot of enterprise implementations, and things like an absolute path will cause a lot of pain down the line.

I'm working on some articles to discuss strategies, but it boils down to keep it simple. Make sure you're using a private repository (ProGet,, or others), don't check-in packages, and if you need a client with more predictable dependency resolution, check out ProGet Client Tools.
Mar 25, 2013 at 3:37 PM
Ok, absolute paths are not ok. How about the getting the list of the .packages from the solution and not from the file placed under the packages directory?
Mar 25, 2013 at 3:40 PM
I'm not very clear what problem you're trying to solve? Is it the "conflicts when one solution with packages will reference (as project reference) another project with packages?"
Mar 25, 2013 at 3:59 PM
Edited Mar 25, 2013 at 4:02 PM
If the information about installed packages is stored in .packages file in each project, why is this information stored in repositories.config file. I think it's unnecessary duplicity.
Mar 25, 2013 at 6:37 PM
It's meant to be an optimization. Searching for all projects in the solution is not as fast as looking at the entries in repositories.config.

Perhaps you can describe what the problem you are facing to help us understand better?
Mar 26, 2013 at 12:34 PM
(Consider the below as a hopefully helpful explanation regarding the stated requirements and where we generally see this exact thing!)

We are often provided similar requirements. Generally where:
  1. Developers are historically used to having a local common library location for all their binary dependencies (ie all hintpaths reference "d:\common" or something similar).
  2. Often this library is controlled centrally and xcopy/robocopied to all developers machines to provide commonality of build capability, generally the central copy come from a CI build system.
  3. There are a lot of different projects that a developer works on with a lot of dependencies, and it is seen as efficient to have a single copy of these dependencies on disk.
  4. Project files are included from multiple solutions at arbitrary locations on disk, resulting in mismatched relative hintpaths when using NuGet.
The repositories.config file does throw up some weird issues when attempting to use a similar pattern with NuGet (regardless of whether this is the "NuGet" way or not), including a repositories.config sitting in a "global" packages directory referencing a (possibly) completely unrelated set of there is some merit to questioning whether this optimisation makes sense long term or for all use cases.

You can already get some pretty weird behaviour just having two projects in unrelated solutions with a nuget.config file within their source path pointing to the same package directory, so this behaviour is being enabled by NuGet but not managed nicely.
Mar 26, 2013 at 5:04 PM
Thank you, Ben, you have nicely described the status quo. And you also pointed out the problem with repositories.config file.
Apr 9, 2013 at 2:32 PM
dotnetjunky - if this is an optimization, I don't fully understand it - do you have any numbers, what was the improvement? I don't think that scanning the solution for entries is so expensive - do you add/remove packages every second that makes it unusable? Also the scan implemented in the GetRepositories method can be improved to use some caching mechanism.

I think that moving this file into .nuget directory (where settings are stored) makes more sense - there won't be any conflicts for multiple solution sharing the same packages directory (the projects must be on the same directory level, which is still a no-go to me).