Package Status Indicators in Visual Studio Solution Explorer #11838
Conversation
| - An up arrow (outdated). | ||
|  | ||
|
|
||
| Hovering over the package and icon will display the respective information for the status. |
There was a problem hiding this comment.
Supporting tool tips in Solution Explorer would require work across three teams: in Solution Explorer (in its hierarchy provider), in CPS and in the .NET Project System.
Currently only tool tip text is displayable for source control provider status. The APIs would need to be extended to allow other kinds of data to be included in tool tips.
|
|
||
|  | ||
|
|
||
| For the sake of not annoying developers, we should only bubble up a warning affordance to the top-level node (Packages and Dependencies) if there is a known top-level vulnerability or deprecated package in their package graph. |
There was a problem hiding this comment.
The current bubble-up logic is based on priority. At each level, the "maximum" level's icon is shown. The order is: error, warning, none. Doing something different here would require some rewriting within the dependencies tree.
| - Vulnerable - "This package has at least one vulnerability with `<severity category>` severity." | ||
| - Outdated - "This package has version `<latest version>` available. | ||
|
|
||
| When right clicking a package, a developer should be able to get to the "Manager NuGet Packages..." context menu action like they can with the "Packages" and "Dependencies" nodes. |
There was a problem hiding this comment.
It would be great if we could have more targeted gestures in these menus for packages. "Manage" is vaguer than "See updates" or "See vulnerabilities".
There was a problem hiding this comment.
I see you've called this out under "Future Possibilities" below.
There was a problem hiding this comment.
Is this where we'd want to open on the Installed tab and and have the package in question selected potentially?
There was a problem hiding this comment.
That's the kind of thing I was thinking, yeah. It'd be useful regardless of the status indicators. Today, right clicking on a package node doesn't provide any way to get to the package manager. If you click on "Packages" you get "Manage NuGet packages". It'd be great to have a command on individual package nodes that opens the package manager with the package pre-selected.
|
|
||
| Because this feature may need some experimentation to get the right signal from the noise and the potential for exponential transitive-level vulnerabilities, developers will need a way to opt-out from the experience as a whole, and options to opt-in to varying levels of information. | ||
|
|
||
| This may need to include a new options panel inside the `Projects and Solutions > SDK-Style Projects` regarding the Package Settings where there's a top-level checkbox for the feature, and either a drop-down indicating a package status level or multiple checkboxes for each status mentioned above. |
There was a problem hiding this comment.
We receive regular requests to make the Dependencies tree general purpose for other kinds of projects, so I try to not think of it as belonging to SDK-style projects, despite the .NET Project System team owning the feature. That said, I don't know offhand of a better options page for such a setting, nor do I think we want to add another page for just a single option.
| <!-- Why should we not do this? --> | ||
| While developers continue to seek this information in more locations, it can also be quite a bit of noise towards the general development experience. Developers tend to compare visual issues in the solution explorer akin to ["DLL Hell"](https://en.wikipedia.org/wiki/DLL_Hell) which we would like to avoid the perception as much as possible while providing valuable information about dependencies. | ||
|
|
||
| This feature can potentially collide with existing experiences in which package dependencies may not exist on disk and/or assets file are incorrect and require a restore to resolve. There can also be false positives/negatives with the current state of the project system and the need to reload projects to refresh the package status in realtime. |
There was a problem hiding this comment.
Could you explain more about false positives that would require reloading projects? I'm not aware of such a situation, for projects opened by the .NET Project System at least.
| <!-- What lessons from other communities can we learn from? --> | ||
| <!-- Are there any resources that are relevant to this proposal? --> | ||
| - NuGet provides status indicators in the NuGet Package manager experience in Visual Studio. | ||
| - Visual Studio for Mac provides "outdated" status indicators in the solution explorer. |
There was a problem hiding this comment.
Can we include a screenshot of how this looks in VS Mac?
|
Moving this proposal to ready as @mckennabarlow is currently working on it. |
|
|
||
| This may need to include a new options panel inside the `Projects and Solutions > SDK-Style Projects` regarding the Package Settings where there's a top-level checkbox for the feature, and either a drop-down indicating a package status level or multiple checkboxes for each status mentioned above. | ||
|
|
||
| <!-- ### Technical explanation --> |
There was a problem hiding this comment.
I'd love to see a technical explanation that focuses on the feasibility of some of these asks. That might allow to define the stages for this work.
Vulnerabilities are going to always be up to date.
What happens with deprecation & update, which are expensive to calculate for example.
Things I'm curious about.
- How often are they going to be done? How frequent should the refresh be?
- Any correctness concerns, given that this simply can't happen at every restore, it'd be an expensive perf hit right now.
There was a problem hiding this comment.
Data about deprecations/vulnerabilities/updates/etc could be handled async relative to the currently project data flow. In VS, the total set of packages in the solution could be gathered and this information queried. Once available, it could be pushed to projects, which could then update project state.
If the data was cached, then solution-load could efficiently load the data during solution load so that we show that state immediately.
The component that manages that state could also be responsible for keeping it updated via whatever means makes sense, such as polling a remote server.
One area I'm curious about is vulnerable transitive dependencies. The project references A which references B, and B is vulnerable. We would want to show A as vulnerable too. Therefore this component would need to model dependencies between packages and push any such state back up the graph to referencing packages, recursively.
There was a problem hiding this comment.
One area I'm curious about is vulnerable transitive dependencies. The project references A which references B, and B is vulnerable. We would want to show A as vulnerable too. Therefore this component would need to model dependencies between packages and push any such state back up the graph to referencing packages, recursively.
Transitive dependencies is definitely an area where we need lots of work.
By default the .NET 8 SDK will report on directs, but transitive dependencies graphs can be really large.
There was a problem hiding this comment.
Given there are commonly many more indirect dependencies than direct dependencies, I wouldn't be surprised if the majority of exposure to vulnerable packages occurs through indirect dependencies.
|
@JonDouglas btw, it'd be great to have the issues assigned to the right folks :) |
|
|
||
| When right clicking a package, a developer should be able to get to the "Manager NuGet Packages..." context menu action like they can with the "Packages" and "Dependencies" nodes. | ||
|
|
||
| Because this feature may need some experimentation to get the right signal from the noise and the potential for exponential transitive-level vulnerabilities, developers will need a way to opt-out from the experience as a whole, and options to opt-in to varying levels of information. |
There was a problem hiding this comment.
This sounds like a perfect candidate to add in the preview features in VS.
| - Vulnerable - "This package has at least one vulnerability with `<severity category>` severity." | ||
| - Outdated - "This package has version `<latest version>` available. | ||
|
|
||
| When right clicking a package, a developer should be able to get to the "Manager NuGet Packages..." context menu action like they can with the "Packages" and "Dependencies" nodes. |
There was a problem hiding this comment.
Is this where we'd want to open on the Installed tab and and have the package in question selected potentially?
|
This PR has been automatically marked as stale because it has no activity for 30 days. It will be closed if no further activity occurs within another 15 days of this comment, unless it has a "Status:Do not auto close" label. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
nkolev92
changed the title
|
Just tidying up here improving the naming :) |
|
This PR has been automatically marked as stale because it has no activity for 30 days. It will be closed if no further activity occurs within another 15 days of this comment, unless it has a "Status:Do not auto close" label. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch. |
ghost
closed this
dotnet-policy-service
bot
removed
the
Status:No recent activity
|
idk why this was closed. stupid robots |
Nigusu-Allehu
added
the
Status:Do not auto close
Introduction to an experience in Visual Studio in which a developer can view the current package statuses in the solution explorer.
This proposal introduces a concept of package status indicators in Visual Studio.
Rendered Spec
Please 👍 or 👎 this comment to help us with the direction of this feature & leave as much feedback/questions/concerns as you'd like on this issue itself and we will get back to you shortly.
Thank You 🎉