The solution consists of 3 projects:
C# application which depends on...
CLR C++ library which in turn depends on...
C++ library
I can debug first two, but not the last one ("No symbols have been loaded for this document"). I am in debug mode (all 3), pdb files were created.
The pdb files for both C++ libraries are created in solution\debug directory. .pdb file for CLR library is also copied to bin\debug directory of the C# project, but not .pdb for the last one. So I copied it there manually, but it didn't help.
So how to debug library which is dependency of the dependency?
I restarted VS, as well as computer, I rebuilt solution too.
Related
I am trying to debug an assembly in a web project. The web project has a reference to the assembly. I have the code for the assembly. I have set the assembly project whose target framework is .Net Standatd 2.0 to Debug build as shown below.
I copied the generated .dll and .pdb files to the \bin\debug\net50 folder of the web project (targets .NET 5.0). During debugging the web project, I noticed in the modules window that Visual Studio loaded the assembly as Optimized and Skipped loading symbols. The dll and .pdb files have the same timestamps. I am not sure why the assembly's symbols are not being loaded.
Then I used this Assembly Information tool and it showed the dll as Release and optimized. So that explains why VS is loading it as such?
My question is why is it being built as Release and optimized?
My goal is getting VS to load it where I can set breakpoints and single step through the assembly code.
There was an Optimize property set to true in the csproj file. Changed it to false.
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 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.
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.
I have a VS 2008 C++ project which uses a third-party library (Open Scene Graph).
When i start debugging the project, each time a function from this external library is called, the debugger just jumps over it, because (obviously) the debugger has no .cpp files where to look up the code. It only jumps into header files which are linked to my project because those files exist and their location is known. So, i can only see what's going on in those small inline functions, but not in the bigger functions whose implementation is in .cpp files which i don't have.
I need is to somehow step thru the source code of these third-party dlls/libs the same way I do with my own code.
I downloaded the the whole source code of that library and compiled it on my machine. Now i have the dlls and libs, and the .pdb files, and the .cpp files, too. But how exactly do I tell Visual Studio the locations of the .cpp files of the third-party library, so that it knows, that when i want to step into a function coming from a .dll or a .lib it opens the corresponding .cpp file (even though it's not in my project and is located is a completely different folder)?
Is this at all possible?
I tried copying the .libs, the .dlls (debug versions), .pdbs both to the locations which my Project uses and "Additional Library Directories" and to the project's folder but this must be not enough.
Add the dir with the PDB files to Tools -> Options -> Debugging -> Symbols.