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.

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

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.

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

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. 👍

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

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.

:)

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

Please file a separate issue for this

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.

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.

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

If the feature is being brought back, why does it need a successor?

Hi Adam, If the future brings back the function, then no successor is required 😉

I am with @damianh - We use this heavily to bring in all build tools. GitHub Releases, Nunit, Code Coverage, Nant etc.

We install Nuget.exe using configuration management globally on the system and then just call nuget restore on the solution. Then our next build step calls all tools from inside packages.

This is an incredibly important feature for us. We built our development environment around it, with solution packages for different project types and roles. Right now it's keeping us from updating to VS 2015, as we would have to redefine a lot of our scripts.

It's worth noting that this feature was actually a bit broken in VS 2013. Two major issues come to mind:

1. Solution packages couldn't reference other solution packages, despite documentation indicating they could
2. When attempting to update from the Nuget Package Manager it would just double install the solution package (two entries appearing the package.config), which then became difficult to uninstall. It worked fine from Package Manager Console, but the GUI was broken.

To prevent changing build tools and scripts every time a new version comes out, we need solution level nuget packages restored without the version folder.

I'd like to add my two-penneth
We distribute our build framework (which is PowerShell scripts, including psake) using nuget. We also package our application code using nuget. Our application code is not .net, it doesn't even get developed in Visual Studio, but we still use nuget because we like it as a mechanism of packaging and distributing a bunch of files as a single artifact.

To aid with installation and updating of those packages we have a .sln file that contains only one thing, a packages.config file. We can successfully install/update packages from Package Manager Console in VS however it seems we cannot do it from nuget.exe as the following screenshot hopefully demonstrates:

This is a problem as we want to write scripts to update all packages across all solutions in one fell swoop.

I have tried to workaround the problem by adding a notionally empty C# project into the solution but I cannot install my nuget packages into that project. I try from Package Manager Console but the project-level packages.config does not get updated.

In short, I'd like a mechanism for using solution-level nuget packages along with the capability of updating them using nuget.exe.

TIA

Please return the feature, we use it in similar to @jamiekt's scenario.

@Lexcess

I was also hoping to see a way for tooling packages that operate at the solution level (such as StyleCop.Analyzers) to be added globally rather than added to projects.

I was under the impression that Roslyn analyzers are specifically designed to work against projects, not solutions, and they are hooked into the build process via the project system.

Solution level packages (in VS2013) are typically exe's, such as unit test runners, which don't fit into this workflow. I.e. they are usually invoked via build scripts and sit outside the MSBuild/VS ecosystem.

If you are proposing changing the Roslyn analyser ecosystem to make it aware of solutions rather than just projects then that seems like a much bigger undertaking. I'm not sure the benefit would be worth the added complexity.

@adamralph I am not proposing this.

@Lexcess then I'm afraid I don't really understand what you are proposing 😄

@adamralph No problem, as I said I mostly wanted to understand how this feature would work, especially given the goal of making it better. Thanks to @yishaigalatzer I get the proposed implementation and that will fix most of our gaps.

Beyond that was the use case of having packages be able to make changes at a solution/global level. StyleCop was my example but anything that might want to say add a sln level configuration, runsettings, targets or a file to solution items would be useful. We can do this already with some creative use of targets but it'd be nice to have in a more supported manner. Given the discussion this seems way beyond the scope of the current issue.

To give an example of how we'd like to use it in a large multi-solution project:
All rulesets for different targets(CSharp, Cpp, CSharpTest & CppTest) would be added to this quality packages, combined with runsettings, clonesettings and Resharper settings. In the projects we'll refer to $(solutionDir)RuleSet4CSharp.ruleset.
This will give me the advantage that we can centrally push these things, without having the need for inclusion in solution as solution items. It also cleans up our repos and avoids a maintenance hell.

@alexdegroot a solution level package is one that does not touch any .csproj files when it is installed.

In the projects we'll refer to $(solutionDir)RuleSet4CSharp.ruleset.

This is a characteristic of a project level package.

I've set up projects where all projects share a single common targets file, and things are pulled in that way. In this scenario a global packages.config file is a great way to pull in a single package to use in dozens of projects without the churn and noise of installing it into them all individually.

@martincostello it's great that you did ;) This is not the bug to discuss it. And this is exactly the reason we want to separate the two issues completely.

1. Global way to install tooling into a project
2. A way to commonize package versions across a solution or reuse package definitions across a solution.

BTW if you move to project.json the churn dies out, all you do is update the project.json files, and your csproj never ever gets touched.

@yishaigalatzer Yay for project.json! ... now if only we can kill off xproj entirely... ;-)

Hi @alpaix. Is solution/tooling level packaging still on track for 3.5 release? Cheers

@JackUkleja We're working on a schedule for 3.5 release. Will update the thread when we get right estimates.

Any news?

ahaha :)
from my msg above (Dec 2015), now I fully use GetNuTool (/core v1.6 - gnt.bat) for all our products.

yeah...

I'm now using Cake which makes it easy to install and run all tooling from NuGet without a solution or project.

no plan to bring this back for now. Dotnet tools (available with 15.7 shortly) will bridge this gap.
https://github.com/dotnet/cli/issues/5147#issuecomment-359836475

Hi @rohit21agrawal ; I can't relate your link to Visual Studio solution restore? Can you please examplify how to replace the ability of automatic package restore on solution level in Visual Studio without doing some kind of pre build script that runs on a project level?