Debug into nuget package libraries

[TheOnlyWei]

Is your feature request related to a problem? Please describe.

I would like it if users did not have to clone a project in order to debug into the relevant C# code, but instead can debug into code from .NET Nuget package libraries. All other SDKs allow you to debug into library code without significant extra configuration but .NET.

In order to debug into PackageReference code, you need to clone the project locally, then provide a ProjectReference such as the below:

<ProjectReference Include="../../../../../../azure-sdk-for-net/sdk/resources/Azure.ResourceManager.Resources/src/Azure.ResourceManager.Resources.csproj"/>

Normally, the above would be imported as in the below, but it seems you can't debug into PackageReference.

<PackageReference Include="Azure.ResourceManager.Resources" Version="1.4.0" />

Maybe there is a configuration for this somewhere, but it's almost impossible to search for it online because anytime you search for "Visual Studio Code" and ".NET", you get a bunch of Visual Studio 2019/2022 results. I could use Visual Studio 2022, but I work with multiple languages frequently in disposable VMs and prefer to keep things light weight.

If the configuration does exist somewhere, it should really be the default behavior to debug into nuget package libraries, and opt-out choice to not make that the behavior as every other language by default allows you to debug into a function code that was imported.

Describe the solution you would like

When I debug a function that goes into a PackageReference in a .csproj file, I would prefer it if I can debug into the actual code. This should be one of the default, basic functionalities of any IDE.

Applicable Scenarios

This scenario applies to debugging.

Describe alternatives you've considered

Alternative is to clone external projects everytime and link it in .csproj using ProjectReference.

[gregg-miskelly]

Is your goal actually just debugging? Or do you want to be able to modify the code you are debugging? If you just want to debug, you don't need to do all this if the project you are trying to debug is properly setup -- publishes PDBs and enables Source Link.

[TheOnlyWei]

Hi @gregg-miskelly , I just want to debug, but I cannot, by default, debug into any of the functions that I am trying to step into, and it isn't obvious if any configuration exists to enable it or why it isn't enabled by default. This is the library I am looking at, but you can probably get the same behavior from any of the Azure SDK projects:

https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/resources/Azure.ResourceManager.Resources/src

[gregg-miskelly]

I updated https://github.com/dotnet/vscode-csharp/wiki/Debugging-into-the-.NET-Runtime-itself with better instructions.

If you are familiar with external code debugging in full Visual Studio, here are the differences with the C# extension --

1. Debugger should support authentication with symbol server and source link #2071 -- Full Visual Studio supports authenticating to symbol servers (and via Source Link). The C# extension only support anonymous access.
2. C# extension should have an equivalent to VS's "No Source" window #1791 -- If the module you are trying to debug into does NOT support Source Link, Visual Studio allows you to browse to find the source file. The C# Extension requires the sourceFileMap option be set up front.
3. Full Visual Studio supports decompiling when symbols or source are unavailable. The C# extension requires a PDB and source files.
4. Full Visual Studio has an 'External Sources' node when debugging in Solution Explorer to allow one to download any document via Source Link. The C# extension doesn't have anything similar, so the only source files downloaded are source files on the call stack.

It doesn't appear we have an issue tracking 3 or 4. So if these are important features to you, please open an issue to help prioritize them in the future.