Hi, I have a project that imports a DLL (written by me). Sometimes when an exception is raised within a method in the DLL, the host project opens a tab and let me see the code within the DLL. I can also put breakpoints within it.
But this behavior seems quite random, I cannot have it on purpose and not always works. Plus, I can't see the file name in the project explorer window.
Any help on debugging DLLs? Thanks
To debug a dll it must have the pdb file with the debugging information that matches that dll.
The enhanced debugging (for a dll not in the current solution) depends largely on whether you have the debugging symbols file (.pdb) in an obvious location - in particular, next to the dll itself. You can also load symbols manually from the modules window (when debugging, Debug -> Windows -> Module, right-click, Load Symbols From...)
Visual studio uses the .Pdb symbols generated by the compile process to enable you the dev to peek at the source when an exception occurs.
This information exists for two reasons. The first reason is for the compiler (i.e., a program that turns source code into an application, such as an .exe or .dll file) to use when it builds the application. The second reason is for people to use when debugging an application. The symbolic information is generated as part of the compilation of an application (if you set the compiler to generate symbolic information). This information can reside directly in the application files, or it can be written to separate symbol files. Where the symbols reside depends on your development application and the settings you choose. For example, Microsoft Visual Basic (VB) builds symbols right into the program files. Visual C++ (VC++) usually builds one or two separate files.
Symbol files have two file types—.dbg and .pdb. The .dbg files are in Common Object File Format (COFF), which is a generic symbol file description that doesn't include source line information; many debuggers can read these files. The .pdb files are a Microsoft format and contain a lot more information than the .dbg files. For example, source line information is available only in .pdb symbols. Symbol files that include source-code line information let you use the source code for debugging.
While it doesn't allow you to debug the code, Reflector is very useful when it comes to inspecting a DLL. The combination of a Stack Trace, the offending DLL and reflector will often get you to the nub of the problem.
What may be getting in your way here is a feature known as Just My Code (JMC). This is a debugger / CLR feature designed at limiting a users view of the world to just the code that they've written. The various ways in how a piece of code or DLL is determined to be yours or not can be confusing at times.
Next time you hit this problem, try disabling JMC and see if it fixes your problem