[SUGGESTION] Option For (Go to definition) to Load Source Over DLL Metadata

[Sour-Codes]

Describe the feature you'd like

tl;dl - Omnisharp's F12 loaded referenced source whereas Language Server Protocol loads DLL's metadata

---

I work on many projects simultaneously. Some are dependent on others. I've always loved that Omnisharp allowed me to edit dependency source code directly in the dependent project. Unfortunately, LSP loads DLL metadata instead of the original source code, even though I add my projects via <ProjectReference />, not <PackageReference />. Can't say how I truly underappreciated a feature until it's robbed from you.

Now, to edit dependencies, I literally need to spin up another editor specific to that file's project, wait for LSP and everything to load just to get intellisense back, just so I can edit/review as easily as I've done during Omnisharp days.

Alternatives considered

Do what Omnisharp did -- have the editor load up the source file so I can simply make the changes I require.

Environment Information

No response

[jasonmalinowski]

@Sour-Codes How are you loading your projects or solutions? This would mean we decided to load the one project but not the dependency.

[Sour-Codes]

With Omnisharp, all of the projects within cwd loads.

For example:

/dirA
|-/projA
  |-projA.csproj
|-/projB
  |-projB.csproj

/dirB
|-/projC
  |-projC.csproj

...where projB.csproj contains <ProjectReference Include="../../dirB/projC/projC.csproj" />...

code /dirA used to follow all dependencies from dirA, which is all three *.csproj files in this example.

Go to definition for any type used to load the source file, even those referenced by <ProjectReference />. That allowed changes directly to referenced projects without having to have a separate instance of code /dirB and having to chase down lines in two editors just to make changes.

[DaveMcCrady]

I agree with @Sour-Codes. This is super annoying. To make this work, I have to temporarily

1. Disable the "C# Dev Kit" plugin. Which disables dependant plugins. (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 Project References

[Sour-Codes]

@DaveMcCrady, thank you for at least finding a workaround. I've just been frustrated about it that I just load up instances to the root of dependencies and just leave the editors open in the background.

I wish there was some sort of transitional period from Omnisharp. If there was one, I clearly didn't get the TPS cover letter update...

Just one day, Omnisharp is ☠️ and I'm opening up and reading on threads about interrupted workflows due to this DevKit swap out.

I just want my daily C# coding to be as hassle less as it was with Omnisharp, which was the driving factor for me to ditch Visual Studio and use VS Code 99.99% of the time (.NET nanoFramework, to Xamarin, to MAUI force you to use VS to debug; otherwise, that software would not be on any of my storage ever...)

I'm almost tempted to just force VSC to use Omnisharp and wait 6 months down the line for a better DevKit upgrade...

[DaveMcCrady]

@Sour-Codes Visual Studio for Mac is being retired (https://shorturl.at/otAFM) so I have been using the DotNet Maui extension for VS Code. (https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.dotnet-maui). Works well with a few limitations, but it depends on the "C# Dev Kit" plugin, which brings me back to disabling the extension every time I need to "Go to definition".

[Sour-Codes]

@DaveMcCrady, I completely forgot VS-Mac is getting canceled and that people do code on Apple products as someone else stated that in another thread of DevKit complaints. From my pov, seems like they should hold off on removing VS-Mac until they figure out this whole DevKit properly.

I stopped using MAUI from its alpha days after being frustrated at how long it takes VS to do anything simple that VSC does. Your response makes me interested to look into it again ... but DevKit though... 😩

[dibarbet]

Similar request here - https://github.com/microsoft/vscode-dotnettools/issues/683

Adding all the referenced projects to the same solution will trigger devkit to fully load the projects (instead of just metadata).

Moving over to the CPS side to consider if they want to support a feature to load projects on demand outside of the solution (cc @lifengl)

[DaveMcCrady]

@dibarbet I am not sure how this is considered a new feature if it is something that has been working since the inception of visual studio / project references, and is now changed, aka "broken".

[jasonmalinowski]

@DaveMcCrady: the behavior we're tracking with this was that we only ever load the projects that are contained in the solution file; if you have a project reference to a project that is not in the loaded solution file, then we'll count that as a metadata reference, which is the behavior that's been in Visual Studio for a very, very long time. Your comment makes me think you're seeing an issue where both projects already are in the solution and it's not working and if so please file a separate bug so we can investigate further since we would absolutely expect that to work.

[lifengl]

@DaveMcCrady : to tell the difference, can you check whether the referenced project is shown inside the solution explorer window? if it is there, it should be a part of your solution file, and "go to definition" is expected to work. Just like @jasonmalinowski said, it would be a bug in the current implementation. If it is not there, maybe your solution file contains a subset of projects, and "go to definition" would get data from the assembly by current design. Changing that would be a feature requirement (as @dibarbet mentioned). Frankly, we can walk project references and load more projects into language service from safe location (or when they are in the same workspace.) However, there is no concept of partial loading a project, it comes with performance overhead. Usually, smaller partial solution files are created by developers to limit projects to be loaded in a large repo to prevent scalability problems. Loading extra projects behind them might not be wanted by others. In smaller repo, usually the solution file covers all projects.

[Sour-Codes]

Just chiming in since my inbox is being blown up about this.

Any idea of when a resolution for this will take place?

As a born and raised New Yorker, I hate dislike things that slow me down in any fashion, like non-east coast drivers, this issue, and *.sln files that keep reappearing, no matter how many decades I spend running from them as if they're like Christmas ghosts.

[UliPlabst]

I'm running into the same issue but all my projects are definitely in the same solution file. C# dev kit even shows all projects in the solution tree, but when I want to navigate to the definition of some types I just get dll metadata. I mean everything works in VisualStudio, it should surely work in C# dev kit also, right?

[jasonmalinowski]

@UliPlabst Can you file a new issue and attach the output of the "C#" output window in VS Code after the solution has been loaded and your navigation didn't work? That sounds like you are hitting some bug since if it works in VS, yes, we absolutely expect that to work in VS Code.

[DaveMcCrady]

@jasonmalinowski

Your comment makes me think you're seeing an issue where both projects already are in the solution and it's not working and if so please file a separate bug so we can investigate further since we would absolutely expect that to work.

The issue is exactly this. The project is referenced as a project reference as follows

<ItemGroup>
    <ProjectReference Include="..\SomeFolder\SomeProj.csproj" />
</ItemGroup>

@lifengl the referenced projects do appear in the solution explorer.

The issue "was" F12/Go to Definition for any object in the referenced project goes to metadata rather than source code.

Having said that, this appears to be fixed somewhere since Nov/2023. The very same project now goes to source for the referenced project as expected. I'm happy! Nobody touch anything!

C# Dev Kit v1.1.16 C# v2.14.8

Version: 1.85.1 (Universal) Commit: 0ee08df0cf4527e40edc9aa28f4b5bd38bbff2b2 Date: 2023-12-13T09:48:06.308Z (3 wks ago) Electron: 25.9.7 ElectronBuildId: 25551756 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin arm64 23.2.0

[jasonmalinowski]

I'm happy! Nobody touch anything!

Good to hear things are working better for you, alas we have other bugs to fix so we can't promise we won't touch anything. :smile:

[DaveMcCrady]

Looks like this issue is back. The only solution is to not use Dev Kit. Extremely frustrating. Enable Dev kit and it's broken. Disable Dev Kit and it functions like it always has.

[jasonmalinowski]

@DaveMcCrady Can you file a new bug with some more details so we can investigate further?