Issue with project level dependencies for projects referenced by multiple solutions

Jun 19, 2011 at 5:04 PM
Edited Jun 19, 2011 at 5:05 PM

I'm trying to figure out what the best way to handle this scenario is:

Let's say I have a project (common library) that's referenced by multiple non-related solutions. Let's call it WebServiceInterface. This library (WebServiceInterface) has a dependency on JSON.NET.  (The gotcha is that typically these common libraries were referenced as a project, not as a binary dependency.)

Before NuGet

The JSON.NET binary was referenced via a SVN external in the WebServiceInterface project. Other solutions which had a dependency on WebServiceInterface referenced the project (also as an SVN external) and as a result pulled both the project, and it's dependencies.

With NuGet

I haven't figured out how to force the JSON.NET reference to be stored under the WebServiceInterface project (as opposed to the RandomSolution\packages location). I found reference @ nu-get to project-level and solution-level pacakges, but I can't seem to find out how to specify this when I add a dependency via nu-get.

Desired Outcome

The goal here is that when someone checks out WebServiceInterface and adds it to a new solution that it builds (instead of having broken references to JSON.NET which point to the packages directory under whatever the last solution was that checked in).

Jun 20, 2011 at 3:47 AM

NuGet doesn't currently support this scenario very well. However, what you can do is install the package from the command line using nuget.exe, and then manually take a reference to it in your project. This way, you can install the package files wherever you want. You will not get the VS integration, but at least it lets you get the relevant assemblies from the NuGet server.

Jun 24, 2011 at 3:44 PM

With "you will not get the VS integration", you're referring to automatically adding content files, Web.config updates, transformed code files, Power Shell fixups, etc., right?

Aren't these features the main reason people love to use NuGet? Don't get me wrong: packaging/unpackaging and automatic dependency resolution is great. But if that's the only NuGet feature left, we're not much better off than managing our external /libs folder by hand IMHO.

I can live without the GUI, but not without the automation.

Jun 24, 2011 at 5:51 PM

Correct, that's what I'm referring to. See my post for related info on this topic.

Jun 27, 2011 at 6:52 PM

Although your article illustrates my point nicely, it does not actually address this specific issue. The cause of the problem here is that NuGet is firmly single-solution minded, i.e., project=solution.

I really don't want (or need) to automate installing packages from outside of VS. I want to do this from inside VS. But the single-solution premise makes it nearly impossible for projects used within multiple solutions to use VS, and the workaround is rather problematic (as in: just forget about it).

I think this is just another illustration why there really needs to be a way to specify the packages folder, and it needs it to be such that it can be solution-agnostic when needed, e.g., a cross-solution packages folder would solve many issues for us.

Does the VS package manager currently honor the (undocumented) nuget.config file next to the solution as suggested in issue 117?

   <repositoryPath>{some path here}</repositoryPath>

I think that would solve some of our problems right now, although a supported option would be even better.

Jun 29, 2011 at 7:04 AM

Understood. The undocumented feature should still work, so please give it a try. It will be good to see whether it works well for your scenario.

But do expect it to potentially change later. In particular, it creates a file in the Packages folder, which we want to move away from because that won't work well in our no-commit scenario.

Jul 20, 2012 at 1:24 AM

Sorry to dig up an old thread, but this is still an issue for many of us, even with the new package restore on build functionality.

Isn't a simple solution to this problem allowing the packages.config file in each project to specify an optional <installPath> element? If it is present, it will install all the packages referenced by that project into the specified path (relative to that packages.config file). If it isn't present, it falls back to the solution level install path.

This does mean you may end up with multiple projects containing multiple copies of the same dependencies (if you specify a local '.\packages\' folder for each project) but with Package Restore that doesn't matter as they shouldn't be committed anyway. And if you still did want a single shared 'lib' or 'packages' folder, you could still specify that with relative paths from the project directory. And because each path is relative to the project that specifies it, it works globally, regardless of how many solutions in various locations reference these projects.

Sep 21, 2012 at 8:24 AM

I'm with Tyson. We've recently started using NuGet on a new suite of services we're building, are there are inter solution dependencies. NuGet is quite simply brilliant on a single solution basis, but starts giving hassle as you refer to projects in other solutions.
Even if you don't directly include the other projects but link to the compiled assemblys, you can run into issues because the other assembly's may have been compiled with difference versions of the NuGet packages.

Keeping many solutions on the same package versions is a nightmare, we do need some way of managing this.

Here's an SO question on same

Thanks guys, keep up the good work. 

Mar 13, 2014 at 4:19 AM
Still a problem, hope they are working on this one...