How to debug (step into) a class library referenced in my project and has .pdb and source code?

Question

When debugging the opened solution/project in Visual Studio (2015) I would like to debug (step into) a method call which is located in one of the referenced assemblies. The assembly has .pdb (copied local) and source code. This assembly actually is also my class lib project, but not in the current solution, instead in an other solution.

I know the trivial solution to debug this assembly would be adding its project to the current solution instead of referencing it, then debugging experience would be seamless. However for some reasons this would not be too efficient in my case, for example there are many assemblies (dozens) which I should add and I do not want to end with a giant solution.

What I've done/tried so far:

• I've unchecked Just my code
• I've checked that .pdb for the other assembly is copied to my current project's output folder.
• Tried to set a breakpoint just before the call, then step into. No success, the call was just stepped over.
• The assembly I would like to debug is coming as a NuGet package (not a simple browsed reference). Still true, it's my class lib project, comes with .pdb, and the source code is available in my local disk.
• Looked at Window->Debug->Modules: Symbol status: Symbols loaded. User Code: N/A. Symbol File location is a Temp Asp Files. (It is an ASP.NET MVC application)
• Because it is coming from a NuGet package its build is a Release build, but currently not optimized, and has the up to date .pdb

As I recall this debugging feature was sometimes surprisingly worked automagically, however now it does not.

What am I missing?

Answer 1

Most common reasons of such experience are:

1. enabled "my code only" (tools->options->debugging)
2. mismatched PDBs
3. mismatched sources

You've ruled out 1, so to check the other 2:

Open Debug->Windows->Modules and find assembly you are having problem with. Make sure it is loaded from location you expect, has version you expect, check if PDBs are loaded. You may need to try load/reload PDB to see if VS is happy with PDB it located.

If PDBs are matching VS should start asking about source location. Information about source is part of PDB so it will let you know if source matches or not (there is option to allow loading mismatched source files, but you'll get funny debugging expirience).

Note that if you library build for RELEASE it will be optimized and for some function you'll not be able to debug them at all due to inlining at JIT time or compile time optimizations of dead code (like if (false) branches). For best expirience make sure to use DEBUG assembly with matching PDB and make sure to attach early with "suppress optimizations on load" in debugger options.

Answer 2

I have faced this problem as well and I have tried many tips. Yet I found out the problem in my context was:

• The desired .dll was installed into GAC (Global Assembly Cache).

I removed it and I could step into the dll code again.