Bring back solution level packages

[yishaigalatzer]

This is an initial strawman suggestion for bringing back solution level packages (work in progress, I plan to update this a bit more, capturing some initial notes)

Why

NuGet 3 supports installing packages that previously where moved to solution level based on content into projects. So theoretically this doesn't prevent developers from using these packages.

However this solution doesn't roundtrip to Visual Studio 2013. And bring it back as it was in Visual Studio 2013 will break developers that adopted the new mechanism and installed these packages into a project.

Suggestion

1. The name should probably be changed, because solution level packages is a misleading name that also collides with the menu - "Manage Packages for Solution".
2. The feature should support explicitly installing packages at the solution level
3. The feature should enable round tripping to Visual Studio 2013 (so the pattern is the same), keeping in mind that since it is going to allow new packages to be installed it might not be 100% roundtrippable, but projects starting from Visual Studio 2013 will be able to go back and forth, assuming you don't install a none supported package in 2015.

CC // @adamralph @davidfowl

[dmccaffery]

As a side note, the NuGet.exe "update" command line currently requires a package.config, solution, or project file as an argument. Packages installed using:

nuget install <SomePackage> -o Package -pre -ExcludeVersion

cannot be updated using nuget.exe.

[yishaigalatzer]

@dmccaffery I don't understand how this comment (although correct, and by design) is related to this issue. Can you please explain?

[dmccaffery]

I suppose, after thinking about it, its not truly related.

Its just my way of getting around the fact that solution-level packages don't exist for the moment. One could add a line to a build script that installs the package in a predefined location; but its impossible to then update that package without first deleting it and reinstalling it -- so its 50% of what a solution-level package provides.

KoreBuild / Sake is one such example.

[yishaigalatzer]

You are right, but you can delete it an install again, which is almost exactly what update would do (except it will rollback on failure, and its a bit more expensive). So that shouldn't block you. And you can always use a packages.config file you author manually and call update on it

[dmccaffery]

Agreed @yishaigalatzer, except that update does a version check to decide whether or not to delete / re-download. Since I am using this as part of a build script, it adds a bit of time to get going that would otherwise be unnecessary. Its not blocking, just... meh.

I guess all that I am asking for, is that any implementation of explicitly installed solution-level packages be supported by the CLI and not just the UI or PoSH console... since the CLI is what I rely on for xplat reasons. DNU is currently limited with respect to package management outside of the scope of a project.json, which makes it less adaptive than its NPM and Bower counterparts.

Thanks for all the hard work; I'm not complaining... just politely nudging. 👍

[yishaigalatzer]

What's wrong with putting it in packages.config and calling NuGet.exe update on that file?

[dmccaffery]

Nothing except staying out of the way of the developer that is using it
My use case is https://github.com/pulsebridge/condo

I could move their packages.config out of the way (if its there), drop my own, call update, and move theirs back; but that is a delicate process. I don't want to muck with theirs (if it exists), or create a dependency where something they change breaks the build, which is otherwise completely self-contained.

I have my work around, and it works. If CLI support for updating a package without a referencing packages.config file isn't in the cards for the future, I can always work around it. It was only a suggestion.

:)

[yishaigalatzer]

It could be. But I don't see it happening soon without a community pull request.

Please file a separate issue for this

[adamralph]

Another reason for bringing back this feature is semantics.

For many tools packages it is counter-intuitive to add them to a project. E.g. a build tool which has the entire solution as it's target of operation. Yes, you can work around it by installing the tool into "some" project, but this is awkward and counter-intuitive. If the semantics dictate that the tool is required for the entire solution and may even be complete unaware of projects within the solution, this should be embraced and expressed by the tooling.

[damianh]

Delighted to see this come back. I use this heavily in commercial and oss project to deliver tooling such as test runners, build tools (psake), etc. Associating these with a specific project really made no sense.

[DoCode]

👍 Please bring back this feature!!
What would be the successor in your mind?