46

We have two solutions: foo.sln and bar.sln

I have a common library that is used by both foo and bar. Common.csproj is used by both.

If I open foo and update nuget references, all references in Common.csproj point to foo/packages/. If I later open bar and update nuget references, all references get set to those in bar/packages/. Naturally, this pisses off the foo team as it can cause incompatibilities between Common.csproj and Foo-specific stuff like Foo.Data.csproj, which still points to foo/packages.

There must be some obvious solution other than: "create a huge solution that contains all your projects, and if you need to touch nuget, only do it from that solution."

There seems to be an issue on codeplex, (the top voted issue, incidentally), but evidently I'm too thick to understand how this issue is resolved. Can someone explain how to fix this?

ckittel
  • 6,478
  • 3
  • 41
  • 71
Code Silverback
  • 3,204
  • 5
  • 32
  • 39
  • I wonder if this has suddenly become an issue as I've been doing it for months without running into problems, there was an update yesterday-ish and suddenly we both run into it within 24 hours. Or maybe it's a coincidence. – GraemeF Sep 16 '11 at 10:10
  • 6
    Also see http://stackoverflow.com/questions/6277925/nu-get-issue-with-project-level-dependences-for-projects-referenced-by-multipl/7908976#7908976. It describes how to change the configuration to specify where the solution will store it's files. If you point all solutions at the same dir, the hint-path should be correct no matter what solution you use. – Reed Rector Apr 10 '12 at 00:15
  • 1
    @ReedRector, you should put the link as an answer, not just as comment. – Michael Freidgeim Oct 18 '12 at 10:51

4 Answers4

38

This problem preceeds NuGet. If you have a project referenced in two solutions, and change assembly references in the project when it is open in one solution, of course it will change the reference path for that project when it is open in the other solution. This has always been the case, regardless of how the reference was changed (with NuGet or otherwise).

But the real problem is that when you do an update, the updated packages do not appear in the foo/packages directory right?

The simple solution is to move Common.csproj into a solution of its own, with its own references, packages folder, build and release process. Then create a NuGet package of your own with any relevant dependencies built into it. Then you can install your Common package into both Foo and Bar and then the Foo team is free to update to the latest version of Common as and when they are ready.

The main argument that I have heard against this is that you might want to step through the Common code while debugging, but this is no longer an issue with Visual Studio 2010.

The fundamental question you need to ask is who owns Common.csproj? Is it the Foo team or the Bar team?

Daniel Dyson
  • 13,192
  • 6
  • 42
  • 73
  • 1
    This is the best answer I have seen to explain this. If I could vote this up ten times I would – ferventcoder Sep 22 '11 at 20:33
  • +1 Just ran into this exact situation and will likely move to this solution (been procrastinating for a while). – Sumo Jun 10 '13 at 20:38
  • 10
    I also just found that NuGet 2.1 can solve this issue. http://docs.nuget.org/docs/release-notes/nuget-2.1#Specify_%e2%80%98packages%e2%80%99_Folder_Location – Sumo Jun 10 '13 at 20:50
7

I fix the problem by changing the hint path in the project fil to contain the $(SolutionDir) variable:

Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>$(SolutionDir)packages\EntityFramework.6.1.3\lib\net40\EntityFramework.dll</HintPath>
Rolf
  • 1,219
  • 2
  • 13
  • 23
1

In our case, many developers and solutions with tfs, and multiple versions of it in different branches ... and each developer their understanding of where the source must lie.

Relative path in this case not work, absolute paths in case of coincidence disc are replaced by relative and also did not work.

Our solution consists in getting rid of the relative path. You can do it if you put NuGetPackages on a separate disk. like so:

net use /persistent:yes p: \\localhost\C$\NuGetPackagesDiskFolder

Any folder name you wont
After that, you can specify realy absolute path in the NuGet.Config 

<config>
<add key="repositorypath" value="p:\NuGetPackages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>

After all delete suo files

ps: Will a little trouble with the alteration of exsisting solutions, if they live in sourcecontrol easiest way is to correcting the path to p:\NuGetPackages in each .csproj Otherwise it is necessary to reinstall all the refs and manually undo all packages.config marked as deleted in the sourcecontrol

aple
  • 11
  • 2
1

Why not have common.csproj as a separate assembly that you reference and has its own dependencies rather than those of the solution its in.

By doing that you protect common from either foo or bar updating the referenced package and breaking it.

Nathan
  • 931
  • 1
  • 12
  • 26