Support language features in metadata / decompiled source files

[dibarbet]

Currently it looks like all metadata as source files are going into the LSP misc workspace. This appears to be because TryAddDocumentToWorkspace never gets called. In VS this is called when the file is opened (the misc files workspace sees it and puts the document in the workspace). Since a solution is never created in the metadata workspace because the file is never added, the metadata workspace is also not registered.

[dibarbet]

Scenarios here

1. Go to definition from metadata references
2. Document outline - Provide outline and breadcrumbs for read-only (generated, decompiled) sources #6341

[daniel-tonic]

Is there any update on this? This seems like a pretty big miss from a feature-parity perspective and it's been several months since this ticket was updated.

[hsm207]

Just encountered #6021 but only for some projects in a solution.

I'm on version 2.22.5 and everytime I reload the window, the C# output pane shows this:

Using dotnet configured on PATH
Dotnet path: /usr/share/dotnet/dotnet
Activating C# + C# Dev Kit...
waiting for named pipe information from server...
[stdout] {"pipeName":"/tmp/c8da874b.sock"}
received named pipe information from server
attempting to connect client to server...
client has connected to server
[Info  - 3:42:10 AM] [Program] Language server initialized
[Error - 3:42:11 AM] Request textDocument/semanticTokens/range failed.
  Message: Unsupported extension '' and LSP language id ''
  Code: -32000 
[object Object]
[Error - 3:42:11 AM] Request textDocument/semanticTokens/range failed.
  Message: Unsupported extension '' and LSP language id ''
  Code: -32000 
[object Object]

[whitecostume]

Still not solved?

[dibarbet]

This should be available in the next prerelease update to the extension. Will update here once it is published.

[dibarbet]

This should now be available in v2.41.26 (pre-release).

[SherbetHead]

@dibarbet, thank you for fixing this. it was working great for a while, but unfortunately I'm having this issue again with the latest pre-release version and the latest release version of c# extension. Your fix was working when vs code was opening source files as "decompiled metadata as source" but it seems that the most recent versions of the c# extension are opening the same source files in a SymbolCache directory.

[dibarbet]

@SherbetHead yeah there is an issue with sourcelink in the latest version. We're working on a fix and should have it out this week.

[HunterZ]

What's the status on this? It's frustrating only being able to navigate one level deep into decompiled code.

[dibarbet]

@HunterZ this should be available in the latest versions of the extension (either release or prerelease). If you're having problems on the latest version, would you mind filing a new issue? Would be helpful to include the C# logs - https://github.com/dotnet/vscode-csharp/blob/main/SUPPORT.md#collecting-general-logs as well as any information on where the symbols you're navigating to are coming from.

[HunterZ]

After having never worked, this suddenly seems to have started working a few days ago. I guess it just took 2-3 months to get into a release version.