New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back solution level packages #1521

Closed
yishaigalatzer opened this Issue Oct 5, 2015 · 59 comments

Comments

Projects
None yet
@yishaigalatzer
Copy link

yishaigalatzer commented Oct 5, 2015

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

@yishaigalatzer yishaigalatzer added this to the Discussions milestone Oct 5, 2015

@dmccaffery

This comment has been minimized.

Copy link

dmccaffery commented Oct 6, 2015

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

This comment has been minimized.

Copy link

yishaigalatzer commented Oct 6, 2015

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

@dmccaffery

This comment has been minimized.

Copy link

dmccaffery commented Oct 6, 2015

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

This comment has been minimized.

Copy link

yishaigalatzer commented Oct 6, 2015

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

This comment has been minimized.

Copy link

dmccaffery commented Oct 6, 2015

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

This comment has been minimized.

Copy link

yishaigalatzer commented Oct 6, 2015

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

@dmccaffery

This comment has been minimized.

Copy link

dmccaffery commented Oct 6, 2015

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

This comment has been minimized.

Copy link

yishaigalatzer commented Oct 6, 2015

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

Please file a separate issue for this

@adamralph

This comment has been minimized.

Copy link

adamralph commented Oct 6, 2015

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

This comment has been minimized.

Copy link

damianh commented Oct 8, 2015

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

This comment has been minimized.

Copy link

DoCode commented Oct 9, 2015

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

@adamralph

This comment has been minimized.

Copy link

adamralph commented Oct 9, 2015

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

@DoCode

This comment has been minimized.

Copy link

DoCode commented Oct 9, 2015

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

@carpnick

This comment has been minimized.

Copy link

carpnick commented Oct 10, 2015

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.

@riplikash

This comment has been minimized.

Copy link

riplikash commented Oct 12, 2015

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.

@yishaigalatzer yishaigalatzer modified the milestones: Client-VNext, Discussions Oct 22, 2015

@programcsharp programcsharp referenced this issue Oct 23, 2015

Open

VS 2015 #2

@yishaigalatzer yishaigalatzer modified the milestones: Client-VNext, 3.4 Oct 31, 2015

@ctaggart

This comment has been minimized.

Copy link

ctaggart commented Nov 5, 2015

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.

@jamiekt

This comment has been minimized.

Copy link

jamiekt commented Nov 16, 2015

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:
2015-11-16_19-55-14

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

@NikGovorov

This comment has been minimized.

Copy link

NikGovorov commented Nov 18, 2015

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

@adamralph

This comment has been minimized.

Copy link

adamralph commented Feb 22, 2016

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.

Isn't that more about MSBuild/VS than NuGet? NuGet can restore an analyzer package at the solution level (i.e. just restore it to the package folder). That part is easy. But at build time, what is then is going to use it and apply the analysis to the code contained in all the projects?

@Lexcess

This comment has been minimized.

Copy link

Lexcess commented Feb 22, 2016

@adamralph

Given the given scope of package restore to a global folder, I think you are probably right.

However, if for a second we accept the notion of global packages that work for the use case of solution level tooling (which is where I and I think others started from), then we'd probably need to see some changes in Nuget to make it work properly (i.e. so that files are restored to a useful place).

From the last few replies I think it's apparent that at best that would be a new feature request or at worst something that Nuget as a project just doesn't want support. I would still like to see a better solution than targets files and empty project files, but perhaps that has to start with the IDE/Build teams rather than nuget. I'd still be interested in the Nuget team's view though.

@adamralph

This comment has been minimized.

Copy link

adamralph commented Feb 22, 2016

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

@Lexcess

This comment has been minimized.

Copy link

Lexcess commented Feb 22, 2016

@adamralph I am not proposing this.

@adamralph

This comment has been minimized.

Copy link

adamralph commented Feb 22, 2016

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

@Lexcess

This comment has been minimized.

Copy link

Lexcess commented Feb 22, 2016

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

@alexdegroot

This comment has been minimized.

Copy link

alexdegroot commented Feb 24, 2016

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.

@adamralph

This comment has been minimized.

Copy link

adamralph commented Feb 25, 2016

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

@martincostello

This comment has been minimized.

Copy link

martincostello commented Feb 25, 2016

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.

@yishaigalatzer

This comment has been minimized.

Copy link

yishaigalatzer commented Feb 25, 2016

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

@dmccaffery

This comment has been minimized.

Copy link

dmccaffery commented Feb 25, 2016

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

@yishaigalatzer yishaigalatzer modified the milestones: 3.5 Beta, 3.5 RC Apr 8, 2016

@JackUkleja

This comment has been minimized.

Copy link

JackUkleja commented Jun 8, 2016

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

@alpaix

This comment has been minimized.

Copy link
Collaborator

alpaix commented Jun 10, 2016

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

@memark

This comment has been minimized.

Copy link

memark commented Jan 10, 2017

Any news?

@3F

This comment has been minimized.

Copy link

3F commented Jan 10, 2017

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

yeah...

@jnm2

This comment has been minimized.

Copy link

jnm2 commented Jan 10, 2017

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

@rohit21agrawal

This comment has been minimized.

Copy link
Contributor

rohit21agrawal commented Feb 2, 2018

no plan to bring this back for now. Dotnet tools (available with 15.7 shortly) will bridge this gap.
dotnet/cli#5147 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment