[SUGGESTION] Add NuGet package reference management to C# Dev Kit, too

[DaRosenberg]

Describe the feature you'd like

Now that we have Solution Explorer and Test Explorer (ish), the one remaining key missing component is a NuGet package reference management in VS Code.

Minimum functionality:

• List installed packages at solution or project level
• List outdated packages at solution or project level, and bulk upgrade
• Browse for packages and add package references at project level

Alternatives considered

No response

Environment Information

No response

[arkalyanms]

cc: @kartheekp-ms as well.

[JonDouglas]

Thank you for filing an issue!

We have four main concepts for this area. Here are some mockups that we would love community feedback on. I won't go into too many details, but there would potential to share the first two options across VS products(Think having the same experience in VS, VS Code, etc). The latter two options are VS-code specific.

1. List WebView 👍:

2. Tabs WebView ❤️:

3. Extensions View 🚀:

4. Tree View 🎉:

Help us vote by using the appropriate reaction to this comment! (1.👍, 2.❤️, 3.🚀, 4.🎉)

[DaRosenberg]

@JonDouglas that's exciting stuff! Those screenshots are too low-res to make out what you have in mind, would you mind updating your comment with higher-resolution screenshots? Can't wait to get a better look!

[JonDouglas]

@DaRosenberg Sorry. Try these.

[DaRosenberg]

Much better @JonDouglas - thanks.

While I am generally partial to platform fidelity (and therefore in theory like the idea of using native VS Code UI paradigms wherever possible) in this case I must say I really prefer the first two because they just seem less constrained, a lot more functionally rich and generally much more usable.

In terms of list vs. tabs, tabs is the clear winner IMO and gets my vote.

Rarely (ever?) is there any value in seeing all those categories of dependencies in the same list simultaneously IMO. Separating these categories into tabs makes for a clearer overview, better progressive reveal, and also gives you more flexibility to vary the rest of the UI based on which tab is currently selected. For example, in the "updates" tab you could show a checkbox on each dependency and an action to update all selected ones.

But - either would be a huge step up from what we have today! 😁

The separation of direct vs. transitive is awesome btw — not even in VS do we have that! 👍🏻

[JonDouglas]

Thanks @DaRosenberg.

We have heard plenty of feedback regarding tabs vs. lists. We will also look into the feasibility of enabling different view-modes based on user preferences. We do know that our VS users love the tabs approach commonly found in many VS package/extension/etc management experiences, but we also want to keep our ears and eyes open for approaches used by the industry as a whole.

For what it is worth the separation of direct vs. transitive has been an experiment that finalized recently and will be enabled for all next Visual Studio release. We sadly ran into some significant performance regressions that needed to be resolved before we rolled it out to all.

https://devblogs.microsoft.com/nuget/introducing-transitive-dependencies-in-visual-studio/

[mamamiawhatacode]

That would be awesome, IMO List WebView and Tabs WebView are beatiful. Looking forward to this in vscode.

[kblok]

Extensions View looks beautiful but I'm concern about how would that look if you have to manager many different projects. Tabs view is quite close to what VS offers.

[Leonardo-Ferreira]

one thing the could be VERY useful is the organization of VS for MAC:

I absolutely love that green "arrow up" which indicates that there is a update to that nuget package

[tmeschter]

Removing area-project as this will be driven from the NuGet side.

[TanvirArjel]

Any update on this? This is the most wanted feature for C# Dev Kit.

[TanvirArjel]

@JonDouglas You took the survey 7 months ago but still no update on progress!

[JonDouglas]

We're working on an initial Visual Studio Code NuGet package management experience including command palette flows and integration with C# Dev Kit. It covers the initial experiences for adding, removing, and updating a NuGet package.

To provide your feedback, please go to: NuGet/Home#13208

[TanvirArjel]

This means the following view is not happening anytime soon: ☹️

[JonDouglas]

@TanvirArjel The team is working towards an initial NuGet experience. Please be sure to provide your feedback.

[Meligy]

@JonDouglas
Option 2 is the best IMO

One thing that classic VS uniquely excels at is consolidation. I'd love to see this in VS Code (and SDK if possible, but VS Code is more important as I use it on Mac, etc.).

[TanvirArjel]

@JonDouglas Hi, I noticed that the merge request NuGet/Home#13208 has been merged, but the functionality is still not available. Could you please provide an update on when it will be available? Thank you.

[michael-hawker]

Really like the prototypes that show the consolidated lists (list, tree, extensions).

That's my biggest gripe with the existing Visual Studio view is that I have to already be changing context to view different pieces vs. getting the general overview. Especially when I go to search for a package to add and then I don't see anything because I'm in my 'installed' tab vs. 'browse'.

Would love to see a new experience tried here to get something fresh and compare against the 'classic' VS design here.

[kazo0]

Love, Love, LOVE the ability to handle NuGet packages through the command palette now thanks to NuGet/Home#13208. Not sure where the best place is for feedback but the only thing I would like to see through the command palette experience is some way to select multiple projects that a NuGet package should be added to. Unless I have missed this and it's already possible

Thank you!

[arkalyanms]

@jebriede fyi

[evgenyvalavin]

I'm not sure where to link this
NuGet/Home#13429

[webreidi]

Closing this initial experience issue. See #1137 to follow the next steps for NuGet in C# Dev Kit.

[JonDouglas]

here is a specific issue for GUI support & I jotted down some ideas on what it could be based on previous concepts:

#1435