This project is read-only.


NuGet package install does not work well when two projects share the same folder


Repro steps:
  1. have two projects sharing the same folder, i.e. open project in windows explorer, the folder being opened is the same
  2. install package to one of the project
  3. install package to another project
Expected: package installation is fine for both projects

Actual: package install will throw a warning that packages.config already existed, skipping. The package install was not successful.

It seems that the two projects are sharing the same packages.config under the same folder.

file attachments

Closed Oct 21, 2013 at 8:18 PM by danliu
Verified using latest 2.8 builds that this feature is in now, so close it. Will file bugs separately.


deepakverma wrote Apr 17, 2013 at 1:23 AM

Prabhu also ran into similar issue. attached project

dotnetjunky wrote Apr 17, 2013 at 10:51 AM

not a supported scenario.

dotnetjunky wrote Apr 18, 2013 at 11:23 PM

Let's see if this work item receives high vote count.

JeffHandley wrote Apr 30, 2013 at 8:47 PM

Talking with @fearthecowboy, this is going to be very common with native projects.

I propose the following when we need to read the packages.config:
  1. Look for {projectname}.packages.config and use it if it exists
  2. Else, fall back to packages.config
We would favor the {projectname}.packages.config so that when we are installing packages, we would find that first before falling back to packages.config. Otherwise, we'd have to look for the {projectname}.packages.config anyway to know that it is being used.

There is a slight risk of harming people if for some crazy chance they already have {projectname}.packages.config, but that seems highly unlikely. To address that, we could add logic such that when reading {projectname}.packages.config, if it's not in our expected format, we abort and fall back to packages.config.

JeffHandley wrote Apr 30, 2013 at 8:50 PM

Pulling out of UpForGrabs to be re-triaged based on new information and proposal.

Haacked wrote May 21, 2013 at 4:43 AM

Just to add my $0.02 to this. This probably affects any library that attempts to be cross-platform. For example, take a look at which is a library that targets Windows Phone, .NET 4.5, etc. etc.

All the project files are in the same solution because they all reference the same files, but have different project settings.

I like the plan proposed by JeffHandley. I wish we had done this from the start. It just wasn't a scenario we considered at the time (Windows Phone didn't exist).

xpaulbettsx wrote May 21, 2013 at 4:44 AM

Huge +1 for this bug, it's extremely useful to keep csprojs in the same folder when you work on cross-platform projects ( for example).

Putting csprojs in separate directories invites a whole raft of workflow issues in VS, putting csprojs in the same folder is by far the easiest way to have the same source built for >n platforms.

dotnetjunky wrote Sep 13, 2013 at 8:30 PM

We will do this in 2.8. The design is as Jeff described above, with a slight modification:
  1. Look for packages.{project name}.config
  2. Look for packages.config
Note that project name will not include the extension. For example, if your project file is CoolProject.cspoj, NuGet will only look for packages.CoolProject.config

johncrim wrote Oct 24, 2014 at 12:46 AM

So presumably the intent is:

packages.config == Packages apply to all projects in the directory, if a more specific packages.(project name).config doesn't exist.
packages.(project name).config == Packages apply to the single specified project.

If so, that's fine - but it still doesn't work correctly, in that if I add a nuget package (using VS integration) to all csproj files in a directory (and I only have packages.config), the package is only added to 1 of the csproj files. It has to be manually added to all the other csproj files.

I'll open another bug for this...

danliu wrote Oct 24, 2014 at 7:16 PM

If you have more than 1 project in the folder, it's recommended to create the packages.<projectname>.config for each of the project in the folder to better distinguish.

But if you have a reason to stick to only one packages.config, please let us know the rationale also in the bug, which will help our triage. Thanks.

bgolinvaux wrote Nov 3, 2014 at 2:26 PM

This feature is very nice and is a real saver for me.

However, I found an annoying bug.

The NuGet visual studio extension will happily recognize the .config file if it is named :


Where ProjectName is either the file name without its extension OR the text value of the <ProjectName> node in the <PropertyGroup Label="Globals"> node of the .vcxproj file (this node allows you to specify a logical project name different from the actual file name).

This can be useful for instance, in the following scenario :


where you do not want the solution view to be cluttered with the _VCxyz suffixes.

HOWEVER, when executing "nuget.exe restore SolutionPath",
only the config files matching packages.ProjectFileName.config file are recognized.

Thus, in my case, it looks for a packages.MyLib_VC100.config file that is not there (since, based on my experiments, I created a single packages.MyLib.config file next to the three projects) and will silently ignore the required packages.

I it useful to be able to have different packages, in our case, for the various projects (VC100, VC110...). However, in that case, the NuGet Visual Studio extension should recognize the same files as the nuget.exe restore command does.

Meanwhile, I'll just remove the ProjectName nodes and bear with the _Suffixes in my solutionview.

If this is not clear, feel free to ask for more details.


danliu wrote Nov 3, 2014 at 7:38 PM

@Benjamin, your bug above sounds more like a feature request. :)

Would you please open a new issue so we can track and triage it separately? Thanks!