Cannot View the Source Code Definitions of csproj ProjectReference Include

[AndrewDRX]

Type: Bug

Issue Description

Debugger is always referencing local ProjectReference included project from a metadata file created at [drive]:/Users/[user]/AppData/Local/Temp/MetadataAsSource/[guid]/DecompilationMetadataAsSourceFileProvider/[guid]/[file].

Steps to Reproduce

First symptoms:

1. Add local project to anoter csproj using a ProjectReference tag.
2. Add code that references function from included project.
3. While using debugger, attempt to step into a function from included local project.
4. Result: Code is always stepped over.

Second symptoms:

1. Add local project to anoter csproj using a ProjectReference tag.
2. Add code that references function from included project.
3. Right-click > "Go to Definition" on function from included project.
4. Result: Navigates to MetadataAsSource file as mentioned in the the description of this issue.

Expected Behavior

Allow viewing of included project code from original included location, rather than using decompiled MetadataAsSource files.

The expected functionality works on version 1.26.0 of the C# extension for vscode.

This issue appears to have started as early as version 2.0.328 available from the vscode extension marketplace.

Version 2.0.320 showed a different issue where the definitions of the included file could not be found when going to Right-click > "Go to Definition", so this new issue may be related to that issue where it is now creating the MetadataAsSource files so that the definitions can be found, but that does not fix the true issue here of not being able to locate the definitions from the original ProjectReference included file path.

Actual Behavior

See section "Steps to Reproduce".

Environment information

VSCode version: 1.82.2 C# Extension: 2.1.2 Using OmniSharp: false

Dotnet Information

.NET SDK: Version: 7.0.401 Commit: eb26aacfec

Runtime Environment: OS Name: Windows OS Version: 10.0.22623 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.401\

Host: Version: 7.0.11 Architecture: x64 Commit: ecb34f85ec

.NET SDKs installed: 7.0.400 [C:\Program Files\dotnet\sdk] 7.0.401 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

global.json file: Not found

Learn more: https://aka.ms/dotnet/info

Download .NET: https://aka.ms/dotnet/download

Visual Studio Code Extensions

Extension	Author	Version	Folder Name
blazorwasm-companion	ms-dotnettools	1.1.4	ms-dotnettools.blazorwasm-companion-1.1.4
csharp	ms-dotnettools	2.1.2	ms-dotnettools.csharp-2.1.2-win32-x64
hexeditor	ms-vscode	1.9.12	ms-vscode.hexeditor-1.9.12
powershell	ms-vscode	2023.6.0	ms-vscode.powershell-2023.6.0
vscode-dotnet-runtime	ms-dotnettools	1.7.3	ms-dotnettools.vscode-dotnet-runtime-1.7.3

Extension version: 2.1.2 VS Code version: Code 1.82.2 (abd2f3db4bdb28f9e95536dfa84d8479f1eb312d, 2023-09-14T05:55:25.390Z) OS version: Windows_NT x64 10.0.22623 Modes:

System Info

Item	Value
CPUs	AMD Ryzen 5 3600 6-Core Processor (12 x 3593)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	undefined
Memory (System)	15.93GB (8.90GB free)
Process Argv	[path] --crash-reporter-id eafc8443-7a05-4e03-8cb9-a0a2d0ad6bbd
Screen Reader	no
VM	0%

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes627:30244334
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
vscorecescf:30445987
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30410667
py29gd2263:30792226
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
pynewext54:30695312
azure-dev_surveyone:30548225
vsccc:30803844
3biah626:30602489
89544117:30613380
vscrpc:30673769
a9j8j154:30646983
showlangstatbar:30737416
0bi6i642:30835152
03d35959:30757346
pythonfmttext:30731395
fixshowwlkth:30771522
showindicator:30805244
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30797651
pythonidxptcf:30805731
pythonnoceb:30805159
dsvsc013:30795093
dsvsc014:30804076
diffeditorv1:30821571
dsvsc015:30829745

[AndrewDRX]

I'll note that I tried:

• Adding <DebugType>portable</DebugType> to the csproj of the included project.
• Adding all of "justMyCode":false, "enableStepFiltering":false and suppressJITOptimizations: true to the launch.json of the main referencing project.
• Adding all of "justMyCode":false, "enableStepFiltering":false and suppressJITOptimizations: true to the settings.json of vscode.

None of which worked, and none of which were needed on version 1.26.0.

[AndrewDRX]

For the "First symptoms", this is a non-issue where I was trying to step into an Iterator function w/out actually iterating over the result. This does work after adding .ToArray() on the result to force the iterator to execute.

For the "Second symptoms", this issue still stands where I can view the source code of the included project w/ the older version of the extension by doing Right-click > "Go to Definition", but on the newer versions it goes to the MetadataAsSource file. This is not ideal, but I can simply work around this by opening the included local project whenever I need to make quick edits.

Given that, feel free to close this issue if you think the 2nd symptoms issue is expected behavior / an expected change in behavior.

[dibarbet]

@AndrewDRX do you have a solution file that contains both projects? I think if you're directly opening the first project itself, the behavior is expected (cc @jasonmalinowski to confirm ).

However if you have a solution file that contains both projects, it should take you directly to the source, not the metadata.

[AndrewDRX]

It is not contained in the Solution b/c it is an independent library that will be packaged separately. In the end, it will be published to NuGet and added as a PackageReference, but I have been using the local ProjectReference in the interim while it is being developed.

The issue here notes a change in behavior between the 1.x.x and the 2.x.x versions of the extension, so if you are confirming that the change in behavior is intended, then this issue can be closed.

[AndrewDRX]

I'll note that I would think of the behavior from the older version as being a Quality-of-Life improvement since the ProjectReference does have the relative path to the local csproj, so there is no technical reason why it shouldn't be able to navigate to the definition of the original source files from that referenced local project.

[Marklb]

This is something I have been relying on and will have to stick with OmniSharp for now, if it does not go back to navigating to the source file.

My use case is mainly for a development tool I wrote a few years ago, but I also used this for other situations also. I wrote a library to act as sort of a LinqPad alternative that initializes the services our webapi uses, to use them from a console script, instead of a controller. We only do that for development or scripts run locally, so I just create a vscode workspace that includes the relatively referenced projects.

Another thing I have used this for is when I don't understand why a library isn't working the way I expected. I will clone the library and change it to a local reference, in my project that uses it, and be able to go to the actual source, instead of a decompiled source, to setup breakpoints in the locally referenced project.

[dibarbet]

Got it. The code is working as written then I believe, but we could consider adding the feature to the Roslyn LSP project loader. I'll leave it to @jasonmalinowski to comment on the feasibility.

[AndrewDRX]

This could technically be considered as a regression issue since this is functionality that was present in the 1.x.x versions. So, I'm not certain that "Feature Request" is the correct tag.

[Marklb]

My reasoning may not be good, but one reason I expect jumping to the source to be the expected is because the debugger jumps to the source. To me, it seems like the debugger "step into" on a method should go to the same place as the editor's "go to Implementation/Definition", since the source is where I would put breakpoints for the debugger.

[AndrewDRX]

Yes, I noticed this as well. The debugger still has no problem finding the original source file; it's just the context menu's goto/peek options for navigating to the source file definitions/implementations.

[DaveMcCrady]

This is super annoying. To properly navigate to project references, I have to temporarily

1. Disable the "C# Dev Kit" plugin. Which disables dependant plugins (MAUI). (reload required)
2. Right-click "Go To Definition", navigate to the source file as expected, then complete the task.
3. When done, re-enable the "C# Dev Kit" plugin and the dependant plugins. (reload required)

This applies to all Project References C# Extension: v2.5.30 C# Dev Kit Extension: v0.5.150

.NET SDK: Version: 7.0.400 Commit: 73bf45718d

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.400/

Host: Version: 7.0.10 Architecture: arm64 Commit: a6dbb800a4

.NET SDKs installed: 6.0.100 [/usr/local/share/dotnet/sdk] 6.0.412 [/usr/local/share/dotnet/sdk] 6.0.413 [/usr/local/share/dotnet/sdk] 7.0.400 [/usr/local/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.20 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.21 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.20 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.21 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[SeijiSuenaga]

Thanks @AndrewDRX for reporting this. It's quite disruptive for me too, since I often use temporary project references in place of eventual package references, as you described. Really hoping for a fix.

[UliPlabst]

I'm running into the same issue as well. I have a solution file containing all projects so I don't know why go to reference is not working. Additionally if I make changes to my referenced project I have build it then reload the window, because Dev kit does not pick up the changes (such as changed function signatures etc.).

[deviant]

Just ran into this when trying to go to definition from a test csproj to the neighboring (shared parent directory) implementation csproj. Disabling the C# devkit extension as suggested by @DaveMcCrady does restore functionality. I'm also not seeing decompiled output as others have mentioned, just a "No definition found for 'MethodName'" when the extension is enabled. I'm working from macOS, although I doubt this is relevant. This is a big enough deal for me that I'm going to have to go back to using Rider for now, but I'd love to help test out a fix.

[AndrewDRX]

@deviant I have since been working around the issue by adding the neighboring project to the solution when working on it as suggested by @dibarbet in this comment: https://github.com/dotnet/vscode-csharp/issues/6375#issuecomment-1722076712

This is certainly more favorable than the whole hassle of disabling/re-enabling the plugin.

There is also a second workaround of getting to the code via stepping through the debugger, as mentioned in this comment by @Marklb: https://github.com/dotnet/vscode-csharp/issues/6375#issuecomment-1726231760

However, I do still consider this to be a regression issue as it worked properly in older versions of the plugin, as I mentioned in this comment in response to @dibarbet removing the Bug label and replacing it with the Feature Request label: https://github.com/dotnet/vscode-csharp/issues/6375#issuecomment-1724701902

Also the fact that the expected behavior works via the debugger stepping into -- just not in the IDE goto def functions -- shows this as a bug.

So, if possible, the labels should be corrected to accurately describe this as a regression bug.

[deviant]

@deviant I have since been working around the issue by adding the neighboring project to the solution when working on it as suggested by @dibarbet in this comment: #6375 (comment)

I've just checked, and both projects are contained within the same solution, so I'm a bit confused here. I appreciate you taking the time to point me at some potential workarounds.

However, I do still consider this to be a regression issue as it worked properly in older versions of the plugin, as I mentioned in this comment in response to @dibarbet removing the Bug label and replacing it with the Feature Request label: #6375 (comment)

[...]

So, if possible, the labels should be corrected to accurately describe this as a regression bug.

Certainly, not to mention the fact that it works without the plugin installed at all, and stops working after installing the plugin!

[Riki-Du]

I have two repo in the same parent folder, the one is the main project (https://github.com/QuantConnect/Lean) and another is an extension (https://github.com/QuantConnect/Lean.Brokerages.InteractiveBrokers). I have linked two projects into one SLN in Lean folder (see screenshot below) and made a successful build.

But the goto definition always lead me to the source under the METADATA instead of going to the right location (Lean/Common/Extensions.cs).

Can anyone help to fix this issue? I think it's really a basic and helpful feature. @dibarbet

[dibarbet]

@Riki-Du can you share a screenshot of the solution explorer? Does it show the sln is loaded and contain both the main project and the extension project? e.g.

It also looks like there was at least one warning loading the project - if you click the 'Projects' icon in yellow at the bottom it should take you to logs. If you could share that as well that would be useful.