Issue in debugging a referenced dll even when pdb file exists in Visual Studio - debugging

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

Related

How can I debug external code in Visual Studio 2019 when there is no PDB available?

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.

Prevent Visual Studio from using cached .pdbs

I did the following experiment: I created a statically linked C++ library solution MyLibrary (I took the code from the MSDN example: https://msdn.microsoft.com/en-us/library/ms235627.aspx.) and built it. Then I created another C++ solution MyConsoleApp, using the console application template in Visual Studio (2017). I copied the MyLibrary.lib file to the root of MyConsoleApp project and added MyLibrary.lib to Linker -> Input -> Additional Dependencies (also had to copy over the headers too of course). What I didn't do was to copy over the MyLibrary.pdb file.
I would've expected to get a linker warning about the missing .pdb file but this was not the case. Then I moved only MyConsoleApp to another machine and tried to build it again, this time getting a missing .pdb linker warning. It seems that Visual Studio is storing the .pdb files when building a solution somewhere on the machine and is able to use those .pdb files when linking other solutions on the same machine.
I would like to be able to disable this behaviour or to be able to remove the cached .pdbs so that I could be sure that when sharing work with other developers they won't get warnings that I'm not getting on my own machine.
Visual Studio doesn't cache the .pdb file. What happens here is that the absolute path to the original .pdb file is stored in the build outputs (.exe, .dll or .obj files) and Visual Studio is able to took it up based on that.
Check this answer for a way to prevent that: Remove PDB references from released file.

Why does Visual Studio ask for cs-files when debugging?

I have included a dll file into my project. I reference it from a library folder where also resides dll's pdb file. When I compile I see both dll and pdb copied to main project's bin folder. On small projects this works wonderfully and I can debug into the dll with no problems. Sometimes, however, in larger projects, VS keeps asking for specific cs files even though their pdb file is included in the projects bin folder. That's ok if I can find those cs files, but it's annoying.
Why is Visual Studio sometimes asking for cs files and sometimes not?
It tries its best given the information it has, but sometimes that information is incomplete. When its ready to give up, it gives you the opportunity to provide the file, just in case you know better.
PDBs generally store the path to the file, as it was when msbuild was invoked to build the DLL. If the paths have changed (e.g. you're on a different machine to where the DLL was built, or just that files on the file system have moved) then the path information doesn't do it much good.
There is a process called source indexing that can embed enough information into the PDBs so that visual studio can re-locate the source files in your source control system (so that you get exactly the correct file as it was at the time of the build) but this is usually an extra step that has to be performed to modify the PDBs after the build has occurred.
Try this (from MSDN Forum)
Tools -> Options -> Debugging -> Symbols -> Empty Symbol Cache (button)
then
Tools -> Options -> Debugging General-> Enable Just My Code (checkbox)
and start debugging again. This should solve the problem if it was initiated by accidental third party components debug symbols that doesn't contains sources but storye only file paths.

Breakpoints don't hit and/or Cannot find or open the PDB

Breakpoints don't hit and Cannot find or open the PDB
My breakpoints aren't hitting in a known good class. I know the class is working becuase the data is flowing through. They worked yesterday. I also tried a class that I haven't touched in weeks (another known good) and the breakpoints wouldn't work there either.
I have:
- Verified I am building in debug mode
- In my solution > Properties Configuration Properties > Configuration I verified each project is set to Debug and Build
- Went to Tools > Options > Debugging and disabled "Enable Just My Code"
- Cleaned and rebuilt the solution
- Restarted Visual Studio
- Rebooted my computer
I have the Modules window open in Debug. Many of my modules show "Cannot find or open the PDB file." Many show "Symbols loaded" (that is good.)
For the files that do not have matching PDBs I right-click and go to Load Symbols From > Symbol Path. Of course there is no PDB in the symbol path. When I right-click and go to Load Symbols From > Microsoft Symbol Servers I get nothing. I have searched the root of my drive looking for these specific PDBs.
Here is an example of the affected DLLs:
Microsoft.CSharp.dll
System.EnterpriseServices.dll
System.Runtime.Serialization.dll
System.Web.WebPages.Deployment.dll
System.Web.ApplicationServices.dll
Based on what I found online the PDB issue is realated, but if I can hit my breakpoints withouth PDBs then I'm happy.
I checked out: Visual Studio 2010 "Cannot find or open the PDB file" with no joy.
I would really like to hit my breakpoints.
Thanks!
PDB files should be in the bin directory along with your other files. They are created when you compile your project. If they are not there, you may have turned them off even while in debug mode. For Vb, look under MyProject->Compile->Advanced Compiler Options and make sure Generate debug info is set to Full. Not sure what the analog in C# is though.
Also for a web project, I had this problem when I had a release version running in the same app-pool as my debug version. Try using a dedicated app pool for your debugging if that's the case.
OK, this is totally embarrassing... I wanted to step through my web services, but to do so I needed to send information from my client application. I had my client app pointing at the wrong server. Bummer.
.Net Reflector can generate the PDB files for most assemblies referenced in your project. I have found it to be extremely helpful.
http://www.red-gate.com/products/dotnet-development/reflector/
Once installed, in Visual Studio: View > .NET Reflector Object Browser > Right click assembly and 'Enable Debugging'

How to set up ReSharper to allow you to navigate to third-party DLL files and view source lines of code?

This confusing feature in ReSharper claims to let you browse external sources from within Visual Studio, see External Sources (ReSharper Web Help).
But, I don't understand what values to set for the folder substitution option. (Resharper - Options - External Sources - Advanced)
When I try navigating to source, I keep getting the message:
PdbNavigator: No sources found in debugging information for in assembly
(This is almost a duplicate of Stack Overflow question Visual Studio - Attach source code to reference, but that post did not explain HOW to attach external sources.
This is tricky, and I finally figured it out:
Click "Show current path settings and PDB files binding" and look at where the PDB points to for source.
Add a folder substitution where the source code is where the PDB says the source code is (probably a path not on your computer, but on the system that compiled the DLL file and PDB). Set the target to the source you downloaded.
Here's a screenshot:

Resources