azure-devopsnuget-packagevisual-studio-debuggingdebug-symbolssymbol-server

Debug NuGet package using Azure Devops Symbole Server resulting to class not found

I've been playing around with Azure Devops lately to host a NuGet package as an artifact, which I would then use in another project of mine. So far so good, I managed to get the package and to use it as intended, but I'd like to be able to debug it as well so I had to add symbols (as far as I've understood?). So I added a publish step in my pipeline for the symbols which succeeds and the .pdb file gets published. I refer to my symbols feed in Visual Studio by connecting to DevOps in the settings Debug > Symbols. When debugging the code it correctly downloads the .pdb file to the temp location and all the whilst the code is running it's staying there. Under the debugger > windows > modules it actually tells me that the symbols are correctly loaded whilst debugging, but as soon as I try to step into the code I get the error: ".cs not found".

IssueAsShown

I've tried multiple things such as clearing the symbols cache, changing settings in debug for "own code only" and "allow source server support" etc. But to no avail.

Did I miss a step or am I doing something horribly wrong?

Solution

  • Debug NuGet package using Azure Devops Symbole Server resulting to class not found

    That because you do not enable Source Link, which supports Visual Studio knows where it should look to download the source code while debugging.

    To debug the source code, we need to have source code, pdb (or /Z7) contains debug information which is like mapping between executable code and your source code. With pdb VS debugger knows where in source files each instruction is located, but it still needs to have source files to show you the code.

    So, we have to enable the Source Link. Edit the .csproj file and include the following code in the first PropertyGroup element:

    <PublishRepositoryUrl>true</PublishRepositoryUrl>
 <EmbedUntrackedSources>true</EmbedUntrackedSources>

    You could check the similar thread for some more details.

    On the other hand, you could also add the source code in the nuget package as a lightweight solution:

    Check my previous thread for details.

    Hope this helps.