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 7: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 12:23 AM

Prabhu also ran into similar issue. attached project

dotnetjunky wrote Apr 17, 2013 at 9:51 AM

not a supported scenario.

dotnetjunky wrote Apr 18, 2013 at 10:23 PM

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

JeffHandley wrote Apr 30, 2013 at 7: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 7:50 PM

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

Haacked wrote May 21, 2013 at 3: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 github.com/reactiveui/reactiveui 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 3: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 (https://github.com/reactiveui/ReactiveUI/tree/rxui5-master/ReactiveUI.Mobile 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 7: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 Thu at 11:46 PM

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 Fri at 6: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.