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.
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 have third-party dll with lib files.
A.dll, A.lib, Ad.lib.
One dll, but two lib files - one for debug other for release. And headers. Is there a way to debug into this dll? I don't have source code and don't have pdb files.
PS: I'm using MS Visual Studio.
That is obvious. You cannot do that. If you want to debug into the dll, you must have the PDB file of it. And there is no other way unless you have the source code in recompile to get PDB file.
Or you could use decompilation tools to parse the dll and get the source code to realize it. But it might have some risks.
I wrote a tool that many users would use on their computers. I noticed however, that users who do not have visual studio installed, cannot open my executable. The error says that msvcp100.dll is missing. I found in internet a redistributable package from microsoft, that should apparently provide these dlls. My question is: is there another way to bypass this problem? Something like an option in the project properties?
Yes, you can change a compiler setting to link the C++ standard library classes into your program instead of having a dependency on the DLL. Right-click your project in the Solution Explorer window, Properties. Switch to the Release configuration (upper left). C/C++, Code Generation, Runtime Library setting. Select /MT.
Only do this when you only have a single monolithic EXE. When you use your own DLLs then you really need msvcr100.dll and msvcp100.dll so that the runtime library gets shared between all modules.
It is part of C++ runtime and the target machine needs it. THere are couple of ways to address it.
Please check following link from Microsoft MCVCP100.DLL
When I'm debugging or even coding, it would be really uesful to examine third party assemblies but I can only see their metadata.
Given that tools like reflector can decompile assemblies, is there someway or some tool which would allow visual studio to do the same thing?
If I happen to have access to the PDB files for an assemblies, would placing them into my applications bin folder allow me to examine the assemblies content through visual studio?
If you have PDB's for a DLL you can certainly examine the DLL while debugging. Make sure that you have "Just My Code Disabled" and you should be good to go
Tools -> Options -> Debugging -> Uncheck "Just my Code"
There is one caveat though, the Visual Studio debugger will not decompile the assembly. It will read source file information from the PDB, if available, and suggest a location to look for the source file. If you do not have access to the source fie you will be forced to look at the machine disassembly (not decompiled IL) while debugging.
You can load the pdbs through the call stack.
Just right click on a function that you want to load the pdb for, then go to 'Load Symbols'. Browse for the correct pdb, and press OK. After that, it should be able to provide information for the calls in that pdb.
Try .NET reflector Pro here.
I believe it's also available in their free version.
Within a Visual Studio (2005/2008) Project I'd like to use an open source library. I'd like to link to the binaries so that I'm not responsible for a proper build and can check those binaries into the source control server (SVN).
So far so good, but if I'd like to debug into the open source library or want to take a look at a class implementation I would be forced to add the the source of the project into my solution and than link my project to the source instead of the binaries.
Is it possible to tell Visual Studio a location of the source of a linked binary library so that things like "go to definition" and debug is working?
Absolutely, if you have the pdb symbols its all done for you - look at MFC for example, you get the binaries yet can debug through the source.
If you don't have the symbols, then its a lot more complicated, when you debug through the code it may ask you to show it the source lines, and you'll just have to find them for it (usually the path is the same so its easy).
There are multiple ways you can achieve this.
Like gbjbaanb suggested you can use pdb symbols. It's going to work for both managed an unmanaged code.
If you're using .NET you can debug with Reflector. Oran Dennison wrote how to debug with Reflector and Visual Studio. One of my favorite tools is TestDriven.NET. Author of this tool, Jamie Cansale, also blogged about how to debug with Reflector when you have TestDriven.NET. In his article, Jamie has a link to screencast where he demonstrates how to do it step by step.
Last, if you use for your SVN client like TortoiseSVN, you can add files/directories from check in. More details how to Ignore Files and Directories with TortoiseSVN.