Solution-Level Packages

Feb 15, 2011 at 1:45 AM

The FAQ mentions something about this, but I can't figure out how this works.

I'd really like to be able to get a package at the solution level, and then reference those packages within each project. Right now it seems like the only thing I can do is reference a package within each project, which seems a little cumbersome.

Is there a way to do this and I'm just missing it?

Jason Bock

Feb 15, 2011 at 5:21 AM

What are you trying to accomplish? I don't think you're looking for solution level packages (a better name is solution only).

Feb 15, 2011 at 1:28 PM

Before NuGet, I'd create an Assets\Binaries folder at the root level. This contained assemblies that were used by the majority (if not all) of the projects in that solution. Rather than copying those assemblies into each project directory and referencing them there, this keeps the source of the assemblies in one spot. With NuGet, I have to reference them all in each project ... though the more I think about it, maybe it's not as big of a deal as I think it is.


Feb 15, 2011 at 3:40 PM

I agree with @jasonbrock...

I do exactly same thing (I have a solution level folder called "Libraries" where I put all dlls shared among solution projects)...

How do we accomplish same with NuGet? 

An example use case would be: Commons.Logging  - If your solution has 10 projects and they all use commons logging you would want to centrally manage this dependency (e.g. update it for all project in one spot)...

If this feature does not exist, can it be added in the next releases?



Feb 15, 2011 at 3:47 PM

Have you guys actually tried NuGet? :) What you describe is basically the way it works today. The libraries are always kept at solution level (under the Packages folder), with each project that needs them just referencing them from that share location.

Feb 15, 2011 at 4:23 PM

As David points out, this is exactly how it works today. We know you don't want to have a binary copied into each project. We know you don't want it copied into bin and referenced from there.

If you take a project like Elmah and install it into 3 projects in the same solution, go to the references tab and you'll see all three projects are referencing the same Elmah.dll. The gesture looks like you're copying into each project, but we notice that it's already installed in the solution and we don't re-download it.

Now in the case of packages that have actual content files (such as JavaScript), we actually do copy it into each project. But that only makes sense since its content. :)

Feb 15, 2011 at 4:41 PM


Damnit, I must've completely missed that when I looked at it. Just tried it again and yep, does exactly what you say. My fault. This works just fine :).


Feb 16, 2011 at 11:58 PM

On a similar note.  So there is a packages folder that is maintained at the solution level and each project references the binaries under it.  How do we handle updates?  Why doesn't NuGet look at this packages folder before going off and obtaining packages from the internet?

Case in point.  I have several projects that all reference Rx-Core package version 1.0.2838.0.  Well a few days ago Microsoft released Rx-Core version 1.0.2856.0.  When I went to add the package to a new project I had created, Nuget proceeded to download the 1.0.2856 version.  However since the build deploys with the 1.0.2838 version, at runtime it threw an error about the wrong version.

I found Nuget just got in the way here, as if I just had a binaries folder and i went to reference the assembly I'd immediately get the version I had there and i wouldn't have to worry about something automatically upgrading me.  I don't mind being notified of updates, I don't mind updates in general, but i want to know about them... and they need to be referenced to every project in the solution not just one.

The way to go back and reference the already downloaded preexisting older version of this assembly was non-intuitive.  I eventually found two ways of accomplishing this, but neither is particularly great.

First way was to drop down to the package manager console and add the package using a install-package with the -source folder option.

The second way was to go into the Nuget Package Manager settings within VS.NET and set our packages folder as an available package source.


It seems to me that the Nuget UI should first look in your packages folder to see what you already have.  I know in 1.1 you added this recent packages, and that might be great for someone who through there day builds dozens of solutions, but for most developers you work in one solution and you are modifying projects.

Or am I missing something? 

Feb 17, 2011 at 1:22 AM
Edited Feb 17, 2011 at 1:41 AM

What you need to do in this case is simply call 'add-bindingredirect' to be able to use the newer version (in the future, we'll make this more automatic). See my series on versioning for more info on that.