Solution wide dependency management

Nov 12, 2010 at 9:57 AM

The project I am working on has about 15-20 projects or so in the solution. Not a big number. Pretty common, I would say.

However, since I have dependencies to Castle, NHibernate, some Rhino projects, Raven, Quartz and Topshelf and some others, dependency management can be pretty time consuming. Especially when third party libraries are compiled with different versions of other third party libraries. A new Castle version can take me hours to migrate into my solution.

There are a couple of thing I see that could speed up dependency management.

A solution wide dependency manager with features like
   - A list of all projects in the solution that would provide an overview of all the projects' dependencies and theirs versions, along with some project settings like target framework etc. where you also can edit dependencies in the list.
   - Possibility to replace dependencies throughout the entire solution. Like "Replace-Package Castle.Core -OldVersion 2.1.0.0 -NewVersion 2.5.1.0 -Solution" or something. (I know there is the Update-Package cmdlet, but I'm talking about where Castle in this case is referenced from my old ../../Lib Hint path).

I hope you get what I mean, even though it might not be entirely thought through. Besides that I think the overview list is my main point here, since expanding the References 'folder' and checking versions is not ideal and the object browser is only helpful sometimes. 

Any thoughts..?

Nov 12, 2010 at 4:59 PM

I agree that having a simple way to visualize the packages and their dependencies in the solution might be useful.  File a suggestion issue! :)

Note that we're moving to a model where we'll be using binding redirect to level dependencies automatically, which will hopefully take care of a lot of cases.

Nov 12, 2010 at 6:14 PM
I like the idea of having an updated package be in the same folder as the prior package (remove the versions from the folder names), that way your references get updated automatically across all projects instead of having to do one at a time. This to me makes for a cleaner upgrade scenario. Having the option to have long named folders (with the version) should also be there, but by default I would want short names (or just the name of the package).

Long Name: fluentnhibernate.v1.1.0.604
Short Name fluentnhibernate

There is no more work to projects when upgrading if the folder name doesn't change and the assemblies are in the same place they were in the prior version. :D


On Fri, Nov 12, 2010 at 10:59 AM, davidebbo <notifications@codeplex.com> wrote:

From: davidebbo

I agree that having a simple way to visualize the packages and their dependencies in the solution might be useful. File a suggestion issue! :)

Note that we're moving to a model where we'll be using binding redirect to level dependencies automatically, which will hopefully take care of a lot of cases.

Read the full discussion online.

To add a post to this discussion, reply to this email (nuget@discussions.codeplex.com)

To start a new discussion for this project, email nuget@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Developer
Nov 12, 2010 at 6:24 PM

Thats a problem when 2 different projects can reference 2 different versions of a library (maybe because of a dependency). It's done that way because side by side is supported at that level. Also, since we're working on http://nuget.codeplex.com/workitem/215, it'll be even more relevant to enable side by side since projects anywhere could be referencing this one package install location.

Nov 12, 2010 at 6:47 PM

One of the things I like about NuGet is the programmability you have using PowerShell. I don't think we should support every possible scenario in the core. As long as NuGet provides the necessary functionality to script a solution, I believe that's where we should focus.

I think that's how Git became so successful. The initial versions were very basic and low-level. Developers built higher level functionality out of these building blocks. After figuring out what worked well, they eventually moved into the core. 

I suggest we follow a similar model. Build core functionality. Empower developers to script using PowerShell. As we learn how NuGet is used, roll some of those features into the core.

Dec 14, 2010 at 2:43 AM

kicking this thread back up.. I dont think the lowerlevel apis are easily accessible in powershell.  at least not without some funky get-interface calls with I can never seem to get right the first ten times I try to cast the com objects.  It seems like I am not able to query project level packages.  I can do a get-package but that does not target a specfic project.  So if two projects had references to two versions of a package I am not sure how to query which packages is referenced by which project.