Nugetgallery: Add a tab for PackageReference on the package details page

[khellang]

In addition to the existing "Package Manager", ".NET CLI" and "Paket CLI" tabs, I'd like to see one for PackageReference:

That would make it really easy to copy a PackageReference XML tag for a specific version and paste it directly into your project file.

Questions that needs answers:

1. What should the name of the tab be?
2. Where would the new tab be placed in relation to the others? What's the ordering?

[anangaur]

@khellang I like the idea but I am not sure this is the recommended flow for users (especially beginners). Some of the drawbacks of directly editing the project files:

1. For Legacy PackageReference projects like WPF, WinForms etc., one will need to unload the project, then edit the project file to add this there. Its not as simple as .NET Core based projects
2. As you suggested, PrivateAssets and other tags that tooling will automatically bring to the PackageReference node based on some metadata on packages. Something not so simple to know with this proposed flow.
3. Where exactly in the project file to put this PackageReference node for somebody adding it for the first time? Though not so hard for advanced users but for beginners this option may cause more confusion.

In addition, I am not sure if we will confuse users working with packages.config with this option. Obviously .NET CLI too doesn't work with packages.config but using the tool will error out while putting this inside the project file for packages.config may result in weird cases.

[khellang]

I am not sure this is the recommended flow for users (especially beginners)

I agree. I'd much rather have a nice UI to do this. Unfortunately, the NuGet UI in Visual Studio is unbearably slow and stuttery. Editing the project file is so much faster.

Sure, it might be a bit confusing the first time for beginners, but does that mean we can't provide convenience for more experienced users? I seriously think you're underestimating the average .NET developer.

If this isn't a recommended flow, why do you provide documentation for it? Adding a PackageReference is literally the first point in the docs, which this tab would link to.

For Legacy PackageReference projects like WPF, WinForms etc., one will need to unload the project, then edit the project file to add this there. Its not as simple as .NET Core based projects

Yes, I'm painfully aware of this, as I do it on a weekly basis. Still, it doesn't mean that this won't be helpful. It'll still save me valuable time compared to typing it out.

As you suggested, PrivateAssets and other tags that tooling will automatically bring to the PackageReference node based on some metadata on packages.

I still think a best effort is better than nothing here.

Where exactly in the project file to put this PackageReference node for somebody adding it for the first time?

This is already detailed in the docs. And chances are that there's already an ItemGroup with package references in there already.

[khellang]

In addition, I am not sure if we will confuse users working with packages.config with this option. Obviously .NET CLI too doesn't work with packages.config but using the tool will error out while putting this inside the project file for packages.config may result in weird cases.

Shouldn't the Visual Studio/MSBuild tooling also error out instead of "resulting in weird cases"? I'd argue this should be the case regardless of this tab in the gallery.

[anangaur]

I do not disagree on the usefulness of this option for advanced users who already know about PackageReference and this option will definitely save some time. My only concern is for beginners who I feel get the most out of these options. And this option may be a distraction for them.

I definitely want this option to be documented - today its missing on the doc topic: Ways to Install a package

[ghuntley]

Devaju/market research over at https://twitter.com/Nick_Craver/status/987658040819273729?s=09

[ghuntley]

In the world of cross-platform, multi targeting, dotnet core and the CPS. I rarely use Visual Studio in any form. I always use sublime, vim or other things when updating packages references because ReactiveUI uses the directory.props convention. Even if tooling was built, I still wouldn't use it. This has value.

[jnm2]

I'm often on a package's NuGet.org page when I want to add it to a project, with the .csproj text editor open in VS Code or Visual Studio. Anything other than allowing copy and paste is going to be making me jump through less-fun hoops. :D

[jnm2]

Another use case for this is installing packages into Directory.Build.props.

[joelverhagen]

Hey @anangaur, what other angles should we consider here? The PR has been open over a year now.

[anangaur]

Merge it!!

[anangaur]

I kept it at abeyance because we were thinking around Central Package Version Management that will not have a version with PackageReference. But lets cross the bridge when we come to it.

[khellang]

Landed in d157ea7

[skofman1]

@khellang , we will close this after it's deployed to nuget.org :)

[khellang]

Oh, sorry 😅

[xavierdecoster]

This is now live! Thanks for the contribution @khellang!