'Go to Symbol in Workspace' doesn't work unless there is an open C# file

[eamodio]

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

VS Code version: 1.11.1
C# Extension version: 1.8.1

Go to Symbol in Workspace only seems to work if there is at least one C# file (editor) open. Originally opened here microsoft/vscode#23584, but was asked to open an issue here (microsoft/vscode#23584 (comment))

I often hit this when working in web projects -- for example I'm working in js/ts or html/css and then need to jump to a backend (C#) class and I try a symbol search and get nothing :)

Steps to reproduce

1. Open a folder

2. With no editors open, do a symbol search for a known symbol

3. No results will be displayed

4. Open a folder

5. Open a C# file

6. Do a symbol search for a known Typescript symbol

7. Results will be displayed

Expected behavior

Results should be displayed in both scenarios

Actual behavior

Results only displayed if there is an open C# file

[DustinCampbell]

This is really a dupe of #1150. Essentially, there isn't a good way to get VS Code to launch C# for VS Code without opening a C# file.

[eamodio]

@DustinCampbell is it really too much overkill to have a small startup that always activates, but does a quick search for any .cs or .csproj or project.json (or any other files that should cause a full activation)? Using something like https://code.visualstudio.com/docs/extensionAPI/vscode-api#workspace.findFiles provide decent options and speed. I'm sure you'd want a setting to either set a the timeout or just disable it. Seems like maybe the spin up/down of the extension when closing and opening C# files would be worse than a small one time start up cost?

[DustinCampbell]

There are a couple of problems with that approach:

1. We would need a second extension to do the start up search to avoid two issues if we built this into VS Code.

   • Launching C# for VS Code whenever a folder is opened would break VS Code's telemetry.
   • Within a VS Code extension, there's no way to know why an extension was activated. So, we wouldn't be able to have a "cheap" launch of C# for VS Code to search for files.

   Of course, there's not a great way to install multiple extensions outside of VS Code's "extension pack" feature, which means that the acquisition of C# for VS Code would suffer.

2. I'm loathe to build ways to work around VS Code activation limitations over working with the VS Code team to just get the right facilities built to meet our needs. We're not the only extension that needs this and there's already an ask for help here (Wildcards on activationEvents.workspaceContains? microsoft/vscode#944).

cc @chrisdias

[eamodio]

Definitely agreed on the last point -- though I think you will need more than just wildcard -- it would also need deep traversal right?

On point 1 wouldn't the telemetry just need to be delayed? And wouldn't the telemetry be broken if vscode supported the fuzzy folder based activation? Since you'd be activated for a folder, and wouldn't get deactivated.

Basically I was just thinking that we'd put something in between the vscode extension activation and the code that runs now (or the code that would run if vscode supported this feature). I was just thinking it would be a tiny shim that could be dropped once vscode added support for the feature.

[DustinCampbell]

I can't think of a way to do that "tiny shim" due to my point about an extension not knowing how is was activated.

[eamodio]

But won't you have the same problem if vscode adds the feature you are requesting?

[DustinCampbell]

Why would we have the same problem? The problem here is about activating the C# extension so that C# features work even before a C# file is opened (such as debugging). If the user opens a folder containing a *.cs or *.csproj, I would expect the extension to be activated. It would be a problem if the extension were loaded even when a *.cs or *.csproj weren't present.

WRT to point #1, that is about VS Code's telemetry around extension activation, not the extension's telemetry. VS Code telemetry would be broken because we'd be activated for any folder even if there wasn't a .cs file anywhere in the workspace. That would have the effort of loading the C# extension even for those just doing JavaScript development, which would skew VS Code's telemetry as it's designed today.

[eamodio]

Ah so now I see that the telemetry would be broken without vscode providing the activation. But other than that (which may not matter -- since I'm guessing that is a deal breaker by itself) -- but unless I'm missing something (which is probably likely) it should be possible to simulate the vscode activation without actually having the feature.

So for example, currently the extension gets activated via activate() in main.ts, but instead its startup could be an activate() in a fictional shim.ts -- which would do the findFiles and decide on whether or not the real main.ts should be activated. EDIT: I glossed over any other events that might have to be watched for, if the extension at that point in time shouldn't be activated (i.e. document opening, etc).

Outside of the telemetry, wouldn't that provide almost the same thing vscode would provide?

[DustinCampbell]

Outside of the telemetry, wouldn't that provide almost the same thing vscode would provide?

Sort of, you'd need more there to know when the user actually opens a folder. There aren't any extension events that VS Code triggers in that case. So, you'd need to poll to see if the workspace rootPath changes or some other logic like that.

[eamodio]

As far as I know (and have seen in GitLens), the extension gets re-activated when the folder changes.

[DustinCampbell]

Does it? The documentation says that "interested extensions will be activated whenever VS Code starts up."

[eamodio]

Yeah, it does for me (both in the debugger and live)

[chrisdias]

You could also activate on the "showAllSymbols" command:

"activationEvents": [
    "onCommand:workbench.action.showAllSymbols"
  ],

When you press CMD+T (the default for showAllSymbols) the extension will get activated.

What I see as a problem is that if you do CMD+P and then # then the command does not seem to be invoked and you won't get activated. I don't know if this is a bug in VS Code or if there is a reason for it, @jrieken ?

[DustinCampbell]

@chrisdias: I'm seeing a problem with the extension being activated for commands it lists in its activationEvents. For example, if I try to use the "Restart OmniSharp" command before the extension is activated, I get an error from VS Code. Is that expected? It seem broken to me.

[chrisdias]

Sounds like a bug to me, can you open issue?

[eamodio]

@DustinCampbell I opened microsoft/vscode#24570 -- it may be false hope, but we'll see where it goes ;)

[DustinCampbell]

@eamodio: It looks like your PR didn't pass VS Code's CI.

[eamodio]

Fingers crossed

EDIT: Doh -- I'm guessing you meant didn't pass -- I have no idea why it isn't passing, I don't see any failures in Travis, and in AppVeyor it seems like a build issue which I don't have locally (nor is it in a file I even changed)

[eamodio]

@DustinCampbell I apparently just needed to kick it again -- now the CI is passing!

[eamodio]

@DustinCampbell its been merged! microsoft/vscode#24570