Skip to content
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

Support navigating to Object Browser from the Dependencies tree #9602

Merged
merged 9 commits into from
Dec 5, 2024

Conversation

drewnoakes
Copy link
Member

@drewnoakes drewnoakes commented Nov 27, 2024

Fixes #4867
Fixes #5643
Preparation for #1256 (needs change in NuGet.Client once this merges).

This change enables the "View in Object Browser" in some new places:

  • On assembly references
  • On project references
  • On framework reference assemblies

It also sets up changes needed for a future change in NuGet.Client that'll add support for the command on NuGet package assemblies.

image

image

image

image

Microsoft Reviewers: Open in CodeFlow

This allows down-level support for several .NET features. In particular I wanted list patterns, but it offers other features too.

The package uses a source generator to add to the project.
This commit adds support for the context menu item "Open in Object Browser", which is added to context menus in the dependencies tree.

The previous command handler only suppressed the menu item in nearly all cases.

This new code adds support for nodes to advertise their support for this feature, and to provide a path to the DLL to browse.

New groups/items are added to the relevant context menus in the VSCT file.

A follow-up change will be made to NuGet, to allow browsing to package DLLs using the new `IObjectBrowserItem` interface added here.
External code that adds `IObjectBrowserItem` items to the dependencies tree needs to use an `IContextMenuController` provided by `RelatableItemBase.CreateContextMenuController`, as this implementation will track the selected item.

This commit adds public API for external code to use.
@drewnoakes drewnoakes added Parity-Legacy-Feature Missing features from the legacy project system. Feature-Dependency-Node "Dependencies" node in Solution Explorer that display project, binary & package references labels Nov 27, 2024
@drewnoakes drewnoakes requested a review from a team as a code owner November 27, 2024 12:22
@@ -60,7 +60,7 @@

<!-- 3rd party -->
<PackageReference Include="Newtonsoft.Json" />
<PackageReference Include="IsExternalInit" PrivateAssets="all" />
<PackageReference Include="PolySharp" PrivateAssets="all" IncludeAssets="runtime; build; native; contentfiles; analyzers" />
Copy link
Contributor

@zewditu zewditu Dec 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish to learn more if there is a document I can refer about such kind setting more properties or constraint in package reference.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this document should cover that info: https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

Let me know if there are specific questions that doc doesn't answer for you.

Note that the change here is based on the recommendation from NuGet.org: https://www.nuget.org/packages/PolySharp/

@zewditu
Copy link
Contributor

zewditu commented Dec 5, 2024

LGTM!
QQ: If the goal is to make "Object Browser" more discoverable, are we able to have an option to get at the solution level for an equivalent of View -> Object browser in main tool bar?
I assumed the view menu object browser show all abject inside the solution.


private string? GetAssemblyPath() => Path is not null
? System.IO.Path.GetFullPath(System.IO.Path.Combine(Framework.Path, Path))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, how does this path look like? are any of the paths rooted?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It ultimately ends up as an absolute path to the assembly, so that we can use it in the object browser and show it in the "Properties" view. The Framework.Path is something like C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.36 and the Path is something like ref\net6.0\Microsoft.CSharp.dll. The GetFullPath just makes the path look normal (i.e. consistent / vs \ characters).


void ShowAssemblyInObjectBrowser()
{
// We're opening a file as a container (DLL).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious, what does it mean to open a file as a container specifically? what other ways are supported?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Container" is terminology from the Object Browser APIs. It basically means DLL, in that it contains types etc. You can also open at a specific symbol (method, property, type, etc), but we just want the DLL.

@@ -30,9 +30,7 @@
ReadOnly="True"
Visible="False">
<StringProperty.DataSource>
<DataSource ItemType="ProjectReference"
PersistedName="Identity"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why were these two properties removed, ItemType and Persistence?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From memory this change makes the returned path be absolute rather than relative. Previously it returned the value of the <ProjectReference Include="../OtherProject/OtherProject.csproj"/> rather than the computed resolved path. We want the resolved path for the Object Browser.

@drewnoakes
Copy link
Member Author

LGTM! QQ: If the goal is to make "Object Browser" more discoverable, are we able to have an option to get at the solution level for an equivalent of View -> Object browser in main tollbar? I assumed the view menu object browser show all abject inside the solution.

Do you mean whether we could have "View in Object Explorer" for the whole solution? I guess so, though it'd probably have to add multiple items to a "component set". I wondered the same thing for a NuGet package, where it would show all assemblies in the package (and possibly those brought in transitively too). Possibly something for a future improvement.

@zewditu
Copy link
Contributor

zewditu commented Dec 5, 2024

LGTM! QQ: If the goal is to make "Object Browser" more discoverable, are we able to have an option to get at the solution level for an equivalent of View -> Object browser in main tollbar? I assumed the view menu object browser show all abject inside the solution.

Do you mean whether we could have "View in Object Explorer" for the whole solution? I guess so, though it'd probably have to add multiple items to a "component set". I wondered the same thing for a NuGet package, where it would show all assemblies in the package (and possibly those brought in transitively too). Possibly something for a future improvement.

Yes!

@drewnoakes drewnoakes merged commit cd57e22 into dotnet:main Dec 5, 2024
5 checks passed
@drewnoakes drewnoakes deleted the dep-tree-object-browser branch December 5, 2024 04:54
@dotnet-policy-service dotnet-policy-service bot added this to the 17.12 milestone Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature-Dependency-Node "Dependencies" node in Solution Explorer that display project, binary & package references Parity-Legacy-Feature Missing features from the legacy project system.
Projects
None yet
3 participants