25
Vote

Short Name folders should be default behavior for NuGet (issues applicable to package-restore as well)

description

This is related to an internal discussion - http://nuget.codeplex.com/discussions/252187. The public details are:

Packages should use short name folders by default (ie. NHibernate instead of NHibernate.3.1.0.4000). This is the same behavior as the override for nuget.exe install nhibernate /x

The scenario for most people is that in one solution they only want one version of a package. So having the version number doesn't make sense and in fact wreaks havoc on source control. I still haven't thought of a valid case where in a single solution you would need two different versions of a package. 90% of the time you want it to be global to the solution.

Allow for someone to put a switch override in to use long names.

Short name folders will slow down the code churn on source control. When we update packages, the current package folder is deleted and readded. Because we are using short names, source control in effect doesn't see that we deleted and readded a folder (because it was done in one operation between check ins). It just sees that we've made changes inside of the folder.


This is related to: http://nuget.codeplex.com/workitem/913
This will help with: http://nuget.codeplex.com/workitem/902

Update 4/17/2012: So summarizing the merge hell aspect of long named folders applies to package restore as well since it affects your .csproj (.vbproj) files. It's even worse if you check the packages folder in. You would still need to deal with the packages.config file and merging, I don't see getting around that.

comments

Haacked wrote Apr 4, 2011 at 4:57 PM

I'm drawing up a list of potential scenarios we'll need to cover. Just as an example, if you have 2 web projects in the same solution both referencing elmah, and you update one of them, what should happen? Should we modify the web.config for both of them? Or simply update the one you selected and now both have the correct assembly reference, but one is broken in config? I would think we need to update both.

ferventcoder wrote Apr 4, 2011 at 6:14 PM

With workitem 913, the idea is that it would loop over all of the projects that have the package installed and perform the update on each of those, doing the normal stuff, so it would update both configs.

Haacked wrote Apr 5, 2011 at 8:58 PM

What if we supported a model where you didn't need to check in the packagest folder (aka we integrate this: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html)?

How important would non-versioned folders be to you?

ferventcoder wrote Apr 5, 2011 at 9:45 PM

I'm in the camp that suggests you check in your third party dependencies. It's going to take awhile for me to move out of that camp. :D

Haacked wrote Apr 5, 2011 at 10:20 PM

Heh. I'm in the same camp, but I had to ask for completeness. :)

markbarb2 wrote Apr 11, 2011 at 4:21 PM

I am firmly in support of this suggestion (short names should be the default). Adding the version number to the folder name can create problems akin to "DLL-Hell".
I also believe that we should check third party dependencies into source control, but that we should use the SCM tool to record and manage the history/versioning of those files, just as we do other source code changes. If there is a need reference two different versions of the same package (e.g. your Elmah example), that could and should be handled as a special case, not the default, just like binding redirection. I believe that this would make it easier for people to develop solutions which are internally consistent about their external dependancies. Scott Hanselman calls this approach creating a "Pit of Success".

RenEvo wrote Apr 13, 2012 at 12:55 AM

Please do this... it is killing us.

RenEvo wrote Apr 17, 2012 at 8:12 PM

The problem we are having is multiple package updates in different branches. Merging between two branches with package updates is causing a lot of merge issues with the .csproj files due to the differing paths to the references, and in some rare cases, causing a lot of developer confusion about where to update to.

We have "tried" to solve this issue with only updating packages in a single branch, but this isn't always ideal.

Use Case: Server/Client - Server publishes packages from "QA" branch builds, Client then needs to update them in "Dev" to start consuming the new API's. Bug comes in from QA, server updates package, now we need to update the package in client's "QA" branch. Merge from QA -> Dev or Dev -> QA now has a lot of issues with the .csproj files. Not to mention this solution has 47 projects on the client.

ferventcoder wrote Apr 17, 2012 at 8:57 PM

So summarizing the merge hell aspect of long named folders applies to package restore as well since it affects your .csproj (.vbproj) files. It's even worse if you check the packages folder in.

You would still need to deal with the packages.config file and merging, I don't see getting around that.

RenEvo wrote Apr 17, 2012 at 8:59 PM

packages.config is an easy merge though and if it breaks, it is an easy fix, .*proj not so much.

FilipDeVos wrote Oct 4, 2013 at 9:02 AM

Short names do not work when you use a "common" packages folder. (can be configured in nuget.config). There you can have multiple solutions sourcing packages from the same "common" folder.