This project is read-only.

Can't set a relative path for a file-based package source


I'm using NuGet 2.1 with multiple solutions, each in a child directory under a single parent directory and a single packages directory which is shared by all the solutions (this became possible with NuGet 2.1).

I'd like to add a file-based package source which points to the packages directory in my working copy (I'm using Subversion).

This works:

<add key="Working copy package source" value="C:\AllMySolutions\_Packages" />
This doesn't:

<add key="Working copy package source" value="_Packages" />

I don't want to hard-code the absolute path but can't find a way of using a relative path in the value attribute inside activePackageSource.

Originally posted on StackOverflow but there've been no responses yet:


JeffHandley wrote Oct 30, 2012 at 10:12 PM

Neat idea, but I'm not sure how we'd define what the "working directory" is consistently. Is it the directory of the solution? Of the project? Which project? Is it the directory of the nuget.config that has this setting?

I think we'd vote for it to be the directory of the nuget.config that has this setting. Would you agree?

tjrobinson wrote Oct 30, 2012 at 10:42 PM

I agree, it should be the directory of the nuget.config that has this setting. This would be consistent with other settings in the nuget.config file, e.g. repositoryPath.

T_Tobler wrote Nov 1, 2012 at 7:00 PM

It's more than "neat", I believe it is required for some team scenarios (the one I'm working on, for example :) ). Without relative paths, I can see no way to really use NUGET easily with our current solution file taxonomy:

git.repo {master}
      /{external dll}.dll
      /{external company}/{proprietary dll}.dll
      /nuget-packages/...  <-- nuget should put packages here; deployment scripts depend on this...
      /{lib 1}/lib1.csproj
      /{lib 2}/lib2.csproj
      /{service 1}
         /service1.sln          <-- includes references to ..\..\Bin\*.dll and ..\..\Libs\*.csproj files, in addition to csproj file
      /{service 2}
(I cannot control where someone might put the git root on their local machine, nor should I.)

My suggestions/vote would be for one of the following solutions:
  1. Add a macro processor when processing the configuration setting value. For example:
  2. Add another setting that defines clearly how the repository path value should be interpreted. For example:

T_Tobler wrote Nov 1, 2012 at 7:02 PM

(folder taxonomy got collapsed... did not expect that... Here are some full path spec examples)


abertier wrote Nov 13, 2012 at 9:57 AM

At our company we use an analog structure as T_Tobler proposed. And I also wanted to add the 'local repository' as a source.

My feeling is that it should always be absolute or 'relative to the config'. To be relative to something else, you should place a nuget.config next to it.

If config is only searched for up in the hierarchy, project-configs will never be encountered. (except if vs-nuget would check the projectdirectories too, but I don't see that need at the moment...)

Yuriksan wrote Jan 24, 2013 at 12:39 PM

+1 for relative (to current nuget.config) paths for packageSources

<add key="Internal Packages Repository" value="..\..\..\MyNuGetFeed" />

Moolie wrote Jan 30, 2013 at 10:40 AM

I would vote for a solution as proposed by T_Tobler, with the path relative to the config file as the most important one.

rgranberg wrote Apr 5, 2013 at 9:22 AM

+1 for relative to nugget.config

rgranberg wrote Apr 5, 2013 at 9:23 AM

That's nuget.config...

mtrtm wrote Apr 16, 2013 at 6:22 PM

+1 for relative to nuget.config. This is NECESSARY for development in teams. Please add this relative to nuget.config or add the ability to use Visual Studio environment variables like $(SolutionDir)

rutavibaja wrote May 14, 2013 at 4:51 PM

Frankly, I am not sure what this feature is for unless we can set a relative path...

Developers will checkout the source to different paths on their machines, it makes absolutely no sense to set an absolute path here.

dotnetjunky wrote May 14, 2013 at 5:27 PM

Local repositories are meant for your local machines only. Individual developers can use it to store their favorites packages, for example. Why does it make no sense?

If you want to share a repository with a team, create a UNC share and make it the repository. Then everyone can share the same repository path.

tjrobinson wrote May 14, 2013 at 9:28 PM


"If you want to share a repository with a team, create a UNC share and make it the repository. Then everyone can share the same repository path."

I understand what you are saying but that doesn't suit every project/team. In our case we have multiple versions/releases/branches that we need to develop/support/maintain. Having a single UNC share isn't suitable as we need to keep the repository in sync with a given version of the code and its dependencies. Having mutiple UNC shares is too much overhead, and shouldn't be necessary.

I'm not saying this is the case for everyone but I would imagine this scenario is quite common. Adding relative path support would enable this for those that need it but wouldn't affect those who are happy with the way things currently work.

dotnetjunky wrote May 15, 2013 at 1:41 AM

I understand that. I'm not rejecting this work item. We will be happy to accept pull request for it.

andersljonsson wrote May 20, 2013 at 7:29 AM

+1 for relative to nuget.config.

DavidVTaylor wrote Aug 27, 2013 at 3:42 AM

+1 Couldn't agree more on this feature. Relative paths would provide much greater flexibility for projects and would avoid hard wiring of absolute paths. The use case which prompted the creation of this issue is spot on for what we would like to accomplish with several of our development projects.

NuGet is becoming much more polished with each release, but still has room for improvement relative to Java tools such as Gradle. Keep up the good work!


tjrobinson wrote Feb 21, 2015 at 10:30 AM

I think this is a duplicate of (fixed). I've not tried it yet.