Search failures in Object Browser and Class View

[verelpode]

Visual Studio Version: 16.8.2

I guess I'm posting this in the right place because I see several open issues mentioning Object Browser, so here's another one related to Object Browser.

Summary

When you use the search box in "Object Browser" or in "Class View" in Visual Studio, and you search for a fully-qualified name such as System.Text.StringBuilder, then VS incorrectly says "Search found no results", despite the fact that it does find System.Text.StringBuilder if you search for only the word StringBuilder without dots.

Search Text	What happens
StringBuilder	Succeeds
StringBu	Succeeds
System.Text.StringBuilder	Fails
Text.StringBuilder	Fails
System.Text.StringBuilder.Capacity	Fails
StringBuilder.Capacity	Fails

Before fixing this, please note the fast tree search method I describe below under "Expected Behavior".

Steps to Reproduce

1. Use VS to make a new C# project using a template such as "Console App (.NET Core)".
2. Optionally change the target framework to the latest version: .NET 5
3. Click "View" menu then "Object Browser".
4. Click "View" menu again then "Class View".
5. In "Object Browser", set "Browse:" to "My Solution".
6. In either "Object Browser" or "Class View", type "System.Text.StringBuilder" (without quotes) in the search box and press the Enter key, and observe that VS fails to find the class.
7. Now search for just the word "StringBuilder" alone and observe that "System.Text.StringBuilder" is found successfully.
8. Repeat the same tests in both the "Class View" and "Object Browser" windows.

Expected Behavior

• When System.Text.StringBuilder is typed into the search box, VS should notice the dots and split the string into 3 separate strings, System, Text, and StringBuilder, and then search for a root-level namespace named System, and then search the child namespaces of System. Search for a child namespace named Text inside System. Then search the Text namespace for a child definition named StringBuilder.
• To avoid slow performance, do NOT search literally for the text System.Text.StringBuilder in a big long list of fully-qualified names -- that's too slow. To be fast and to produce correct results, navigate the tree as explained in the previous point.
• If zero matching results are found when using the aforementioned tree method, then VS could resort to a slower method of searching that finds more results, such as searching for partial matches.

Actual Current Behavior

• When you search, VS temporarily freezes because the search algorithm is so slow, and because the search isn't performed in a separate thread.
• VS fails to find fully-qualified names such as System.Text.StringBuilder.
• VS fails to find partially-qualified names such as Text.StringBuilder.
• VS succeeds when the user searches for an unqualified name such as StringBuilder without any dots.
• VS fails to find members of classes/structs/types, such as failing to find the member when you search for the fully-qualified name System.Text.StringBuilder.Capacity and also failing when you search for the partially-qualified name StringBuilder.Capacity.

User Impact

• I use "Object Browser" and "Class View" very frequently, multiple times every day, but unfortunately Visual Studio wastes a lot of my time because of the failure to support dots in the search box, causing me to manually search without using the search box or to suffer a very long list of search results because it only lets me search for words without dots.
• Unfortunately it also wastes a lot of my time each day because of the slow performance / temporary freezes, repeated many times per day while I work. The aforementioned tree method should greatly improve performance when searching for fully-qualified names such as System.Text.StringBuilder.

Screenshots

[drewnoakes]

@verelpode the Object Browser is not in this repo, nor is it owned by this team. The issues you see in this repo relate to menus that launch the feature. Can you use the "Report a Problem" feature of VS to create a feedback ticket that can be routed to the correct team? Thanks.

[verelpode]

@drewnoakes -- Does the "Solution Explorer" fall within this repo/team? Does the following info make this issue relevant to this repo/team?

Firstly, consider the fact that the default layout of Visual Studio, and the layout used by most people (AFAIK) is with "Solution Explorer" being important and kept open on the righthand side like this screenshot:

Isn't that BAD? We all do that, including myself, but we're doing it wrong, aren't we?

Shouldn't we close or de-emphasize "Solution Explorer" and instead place "Object Browser" (or "Class View") in the place of "Solution Explorer" ? Like this:

Isn't "Object Browser" actually a better, more effective, more productive design than "Solution Explorer"? Or it could be, if a few problems in Object Browser would be fixed.

If the "Solution Explorer" falls within this repo/team, then perhaps we could discuss how "Solution Explorer" could be redesigned to operate more like "Object Browser" and "Class View", or perhaps how these 3 panels/windows could be merged into "One panel to rule them all", to deliver enhanced productivity. What do you think?

Re "Report a Problem":
I was really hoping to post the "Object Browser" report in a GitHub repo, because I've already used the "Report a Problem" feature a bunch of times during the last few years -- unsuccessfully. In my experience, posts to GitHub repos are often more effective than the "Report a Problem" feature.

I've been suffering various "Object Browser" and/or "Class View" problems for years, and it feels like a reliable good version of "Object Browser" will never be delivered, because Object Browser bug reports via "Report a Problem" tend to have little or no effect, it seems, and no corresponding GitHub repo exists for Object Browser and Class View.

Don't many people use "Object Browser" and/or "Class View" frequently, every day ?
If "Object Browser" is not used frequently, then how can Visual Studio be used in a practical and effective manner without Object Browser and/or Class View?

I realize one alternative is to use the web-based docs.microsoft.com but this doesn't work for all the non-Microsoft classes present in a .csproj, and for the .csproj's own internal classes. Also online documentation is slower than offline, and the lost time adds up to a significant amount of lost time/productivity per month and even more per year. Actually the offline Object Browser is also slow and causes lost time to add up, so it seems no good solution exists, despite the fact that this part of Visual Studio is something essential that needs to be used multiple times every day.

Another alternative is to use IntelliSense instead of Object Browser / Class View, and I do love and use IntelliSense, but I've noticed that when I use IntelliSense alone without Object Browser, again I end up suffering significant lost time/productivity because IntelliSense doesn't provide all info that Object Browser / Class View provide.

What do you think about the idea of discussing a new design or replacement of "Solution Explorer" that operates more like "Object Browser" and "Class View" instead of focusing on files? Or maybe merging these 3 panels into "One panel to rule them all" ?

The core problem is that AFAIK we all seem to focus on the files ("Solution Explorer") whereas actually it would be better if we focus on something more like "Object Browser" or "Class View" instead of the files.

Especially nowadays in team development and online "Source Control" management systems, team members actually work on (or should actually be working on) particular classes not particular files. In a modern "Source Control" management system, it would actually make more sense for a team member to upload a new version of a class, NOT a new version of a file that contains a class. Thus our focus on the files in "Solution Explorer" isn't the right focus, because it's more effective to focus on classes instead of files.

[drewnoakes]

Does the "Solution Explorer" fall within this repo/team?

This repo only covers the .NET Project System. It's the subsystem that loads a .NET Project and integrates it with other parts of VS.

Solution Explorer is core to VS, language agnostic and not specific to .NET. It's an internal part of the product, not hosted on GitHub. The team that owns it won't see any issues here on GitHub.

Your ideas here are better submitted through Developer Community where they can get in front of the right people.

[jjmew]

@verelpode This is something that is owned by the Visual Studio team not the .NET Project system. The best way to submit feedback directly to Visual Studio. Here are the instructions : https://docs.microsoft.com/en-us/visualstudio/ide/how-to-report-a-problem-with-visual-studio?view=vs-2019