I am unable to step into NuGet packages (either hosted in a folder, or on a server - in my case MyGet) compiled with symbols when attempting to debug into a .NET Framework class library (in my case an nUnit test project). I have tried everything here -
How to debug code in a nuget package created by me
To summarise what I have tried:
1) Compiling package with symbols, adding the folder containing the symbols.nupkg to the solution I'm debugging's Debug Source Files list. Adding the folder to the list in Tools -> Options -> Debugging -> Symbols. Tried 'load all modules' and 'load only specified modules'.
2) Enabling / Disabling 'Just My Code'
3) Manually copying the pdb files from the package project into my project's bin folder, no idea why this would still not work but it doesn't...
4) Adding the 'SourceLink.Create.CommandLine' package to my project.
5) Using a symbol source server (provided by MyGet)
EDIT: It appears that the debugger is using the versions in Temporary ASP.NET files, and only some have the PDB loaded for some reason. No matter what I use, symbol server, PDB files in the bin directory, it insists on only putting the DLL into Temp ASP.NET files.
All the DLLs here have been compiled with the 'Full' 'Debugging information' option, are not optimised, have the DEBUG/TRACE consts set, have the PDB inside the symbols.nupkg file - basically there is nothing special about the ones with the PDB in Temp ASP.NET versus the ones without :/
.snupkg is not an option for me as I'm using VS 2017.
I finally got this to work with this process:
1) Set up MyGet as the NuGet and symbol server.
2) 'Just My Code' can be enabled.
3) 'Source server support' can be disabled.
4) Options -> Debugging -> Empty Symbol Cache.
5) Options -> NuGet -> Clear NuGet Cache
6) Restore packages, build and run.
This works consistently for me with MyGet, but not with locally hosted symbols (in a folder).
Debugging into NuGet packages (again..) VS 2017
If you are not deploy the symbol package to SymbolSource server, you could not step into your nuget package, even if you have added the symbols folder to the solution. That because Visual Studio could not parse .pdb file in the nuget package.
For some details info, you can check another thread about this issue.
And, as a lightweight solution to debug the nuget package, you can use following method:
Is it possible to host both regular and symbols packages in a NuGet local feed on a network share?
Besides, MS team create a new .snupkg extension which creates a streamlined package debugging experience for the entire NuGet ecosystem. You can check the document for some more info:
NuGet Package Debugging & Symbols Improvements
Hope this helps.
Related
I am trying to debug some issues occurring within an external library (ClosedXML). If I can work out exactly what's going wrong, I should be able to apply workarounds to the code that calls it.
I have added ClosedXML and manage it via NuGet.
Unfortunately, the debugger states that ClosedXML.PDB cannot be loaded. The checkboxes for 'Microsoft Symbol Servers' and 'NuGet.org Symbol Server' are both checked.
A suggestion was to generate my own pdb file. So, I cloned the ClosedXML repo, checked out the 0.95.4 commit (the version of the NuGet package I'm using) and built the project in Debug mode. I then directly referenced the pdbs produced in the ClosedXML binaries folder in the 'No Symbols Loaded' page in Visual Studio. Unfortunately, none of them work. They each have the same error message:
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net46\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\net40\ClosedXML.pdb: PDB does not match image.
...\source\repos\ClosedXML\ClosedXML\bin\Debug\netstandard2.0\ClosedXML.pdb: PDB does not match image.
This isn't surprising as the DLL and the PDB weren't built on the same machine, but it is unfortunate.
So, my current workaround is to dereference the NuGet package and instead reference the DLL I've built locally. This works, but it is far from ideal.
To confirm, 'Just My Code' is disabled.
Is there any way I can debug the external code without resorting to changing references each time?
You can use my Runtime Flow tool to investigate called methods and parameters in ClosedXML without .pdb.
I try to use Azure DevOps Server (on prem) the output of the Index sources and publish symbols task as Symbol Input for the Visual Studio Debugger. Therefore I copy the task output to a local directory on my machine and configure the Symbol file (.pdb) locations on VS to that path.
The Symbols comes from a NuGet Package (name: ExceptionPackage) I created specially for that use case. The packages only purpose is to throw an exception on calling different function to test the Symbol Debugging with VS.
The VS Debug Settings for the Symbol file locations looks like:
When I run my test code, the Debugger is not able to give me a full Call Stack of the NuGet Package, even when I add all levels of my Symbol path (C:\Users\m**\Desktop\DebugTest\Symbols is the root folder with multiple symbol sources). Is the root path enough for VS?
So how do I get the full the Call Stack of the Exception inside my NuGet Package? Is my approach wrong?
VS General Debugger Settings:
Versions:
Azure DevOps Server: 17.153.29207.5 (AzureDevOps2019.Update1)
Visual Studio 2019: 16.7.7
Use Azure DevOps Symbols for Visual Studio Debug Symbol Source
I could also reproduce this issue on my side. I check the Symbols load information from the Modules Window:
I get the error PDB does not match image.. Even if I match the pdb file manually, it still not work:
Then I found this thread about this issue.
To debug the nuget package, you could try to use the lightweight solution to debug the nuget package:
Is it possible to host both regular and symbols packages in a NuGet local feed on a network share?
And if possible, please check if this thread give any helps.
I have packaged and published a symbols nuget packages for an internal class library within our VSTS environment. When I install the nuget package the bin folder gets the dll and pdb files.
When I try to step into the code it asks for the location of the source code file. If I do not specify the location I review Source Search information. It looks to be looking for the source code in the path specified with the VSTS Builder.
I know you can specify the symbols location with Tools -> Options -> Debugging area. However, I have multiple projects so would I have to define the symbols location for each project?
Is there a way to have it reference to the package folder by default?
I have 2 solutions, Source.sln and Client.sln both containing multiple projects.
After compiling Source I will copy all the dll and pdb to a Lib folder so that the projects in Client can use it. I added dll reference to this Lib folder for required projects in Client.
While debugging I couldn't step into the code of projects in source. I have referred so many SO and MSDN questions and did many changes. Apart from the steps performed below , could someone help me out to resolve this.
Clean and Build solution in Source. Copied new dll and pdb to Lib folder.
Enable Just my code is unchecked in debugger settings
Target framework matches in all projects
Symbol cache cleared
Debug info is set to full in Build-> Advanced Tab. Configuration is Debug
Deleted suo file from solution
Also tried to map the pdb at runtime from Debug-> Windows->Modules and for the specific dll. Getting an error like 'a matching symbol file was not found in this folder'
Please note that I am running a Unit Test
I've included a NuGet package (Edge.js) that I would like to debug by stepping into the source code. When I "step in" it "steps over". I'm guessing this is because there are no symbol file to step in to. Possibly the EdgeJS package was published without sources and this could be the reason. However I don't know how to verify if a NuGet package contains the pdb symbols.
It might also be that I failed configuration of Visual Studio but because I don't know if the NuGet package contains symbols I don't know which way to look.
Thanks for any help
Nuget supports creating packages that contain PDB and source files with the nuget pack -Symbols command. Usually, these packages are uploaded to symbolsource.org for open source projects. Visual Studio can be configured to use symbolsource.org during debugging, see this guide.
However, not every open source project uploads symbol packages to symbolsource.org, so you have to check whether Edge.js does (I don't know that library).
If Edge.js does not provide symbol packages, your options are as follows:
Download the edge.js sources and build locally with debug symbols. Copy the DLL and the PDB to the output folder of your application and start debugging.
Use a decompiler. You don't get as much information as with the debug symbols and source files, but it may suffice for your case. The decompiler that ships with Resharper (commercial tool) is pretty useful for debugging DLLs in this manner.
You can't "step-into" anything if you don't have the source code. Debug symbols won't help in this case.
You can step-into the decompiled code only by using third-party tools like RedGate's Reflector or Telerik's JustCode that decompile the IL on the fly and generate C# code for viewing purposes. These tools don't need the debug symbols to work, although they can use them to make the decompiled code more presentable.