-
Notifications
You must be signed in to change notification settings - Fork 390
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
Conversation
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.
@@ -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" /> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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/
LGTM! |
|
||
private string? GetAssemblyPath() => Path is not null | ||
? System.IO.Path.GetFullPath(System.IO.Path.Combine(Framework.Path, Path)) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
...ProjectSystem.Managed.VS/ProjectSystem/VS/Tree/Dependencies/Commands/ObjectBrowserCommand.cs
Outdated
Show resolved
Hide resolved
|
||
void ShowAssemblyInObjectBrowser() | ||
{ | ||
// We're opening a file as a container (DLL). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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! |
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:
It also sets up changes needed for a future change in NuGet.Client that'll add support for the command on NuGet package assemblies.
Microsoft Reviewers: Open in CodeFlow