roslyn: Go-to definition doesn't work anymore on project references

Environment data

dotnet --info output:

% dotnet --info
.NET SDK:
 Version:   7.0.102
 Commit:    4bbdd14480

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.102/

Host:
  Version:      7.0.2
  Architecture: arm64
  Commit:       d037e070eb

.NET SDKs installed:
  6.0.405 [/usr/local/share/dotnet/sdk]
  7.0.102 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

VS Code version: 1.78.2 (Universal) C# Extension version: 2.0.206 (Pre-Release)

Steps to reproduce

Open a project directory
Make sure the solution explorer is loaded and you see the solution and its projects
Have 2 projects on the solution
Add a reference from one project to another (doesn’t matter which one)
From the project which has the reference try to use a type from the referenced project
Press F12 (go to definition)

Expected behavior

Since it is a project reference, I was expecting the “old” behavior to persist which is go to the file on the referenced project which defines the type/method.

Actual behavior

What is actually happening is that it is opening a read-only tab. Like if it was reading the type metadata from using the assembly explorer. You can see the path on the top pointing to <referencedProjectPath>/obj/Debug/net7.0/ref/xxx.dll.

This behavior is ok if we are using a type from a reference assembly or a package reference, but not for project references.

About this issue

Original URL
State: closed
Created a year ago
Reactions: 5
Comments: 20 (18 by maintainers)

Commits related to this issue

Ensure we don't run both project systems at once When we were looking to see if Dev Kit was installed to know whether we should trigger our own project system, we checked _wasActivatedWithCSharpDevki... — committed to dotnet/vscode-csharp by jasonmalinowski a year ago

Most upvoted comments

@chsienki Can you ptal. We’ve been getting a bunch of reports about this. It all appears to be in the generator layer:

specifically:

[Error - 3:43:44 PM] Request codeLens/resolve failed.
  Message: SyntaxTree is not part of the compilation (Parameter 'syntaxTree')
  Code: -32000 
[object Object]
[Error - 3:43:45 PM] [LanguageServerHost]System.ArgumentException: SyntaxTree is not part of the compilation (Parameter 'syntaxTree')
   at Microsoft.CodeAnalysis.CSharp.CSharpCompilation.GetSemanticModel(SyntaxTree syntaxTree, Boolean ignoreAccessibility) in /_/src/Compilers/CSharp/Portable/Compilation/CSharpCompilation.cs:line 2326
   at Microsoft.CodeAnalysis.Diagnostics.SuppressMessageAttributeState.IsDiagnosticSuppressed(Diagnostic diagnostic, SuppressMessageInfo& info) in /_/src/Compilers/Core/Portable/DiagnosticAnalyzer/SuppressMessageAttributeState.cs:line 175
   at Microsoft.CodeAnalysis.Diagnostics.SuppressMessageAttributeState.ApplySourceSuppressions(Diagnostic diagnostic) in /_/src/Compilers/Core/Portable/DiagnosticAnalyzer/SuppressMessageAttributeState.cs:line 122
   at Microsoft.CodeAnalysis.GeneratorDriver.FilterDiagnostics(Compilation compilation, ImmutableArray`1 generatorDiagnostics, DiagnosticBag driverDiagnostics, CancellationToken cancellationToken) in /_/src/Compilers/Core/Portable/SourceGeneration/GeneratorDriver.cs:line 388
   at Microsoft.CodeAnalysis.GeneratorDriver.RunGeneratorsCore(Compilation compilation, DiagnosticBag diagnosticsBag, CancellationToken cancellationToken) in /_/src/Compilers/Core/Portable/SourceGeneration/GeneratorDriver.cs:line 312

This is all called from an IDE call that just asks the system to check a compilation. But we’re somehow ending up talking about a syntax tree that the compilation itself doesn’t seem to know about. Seems bad 😃

CyrusNajmabadi on Jun 14, 2023

Awesome! I can confirm it is working properly now. Thank you!

galvesribeiro on Jun 14, 2023

This is now fixed with version 2.0.212 of the C# extension we shipped earlier today.

jasonmalinowski on Jun 14, 2023

Another symptom of this issue is that if I modify a file on that referenced project, like add a new type, and build the solution from VSCode (either right click > build or Cmd+Shift+B), it will not have that type available on the project referencing it.

Even after “Reload Window” or full restart VSCode it just don’t detect the type. It only got available after dotnet build --no-incremental from the terminal. Seems like it keeps looking for stale references.

galvesribeiro on Jun 7, 2023

More reports here as well - https://github.com/dotnet/vscode-csharp/issues/5711

dibarbet on Jun 7, 2023

Hey guys thanks for the quick replies. When I submitted the issue it was on closed source project. After reading your message I went thru trying it with Orleans in a PR I was working with and got the same behavior:

I believe you can try with the original Orleans repo but just to make sure we are trying the same thing, get from my fork: https://github.com/galvesribeiro/orleans

Look for the branch google-providers. I can reproduce it on multiple files, but to simplify the case go to the file:

Then F12 on the IGrainStorage interface. You will see it won’t get the P2P reference but instead the metadata one.

LMK what I can do to help to debug the issue in case you can’t reproduce it. I’m enjoying the new experience/extension in VSCode overall, just some quirks like this that slow us down 😄

Thanks!

galvesribeiro on Jun 7, 2023