Not so long ago Microsoft has made .NET source code browsable through a really nice page: http://referencesource.microsoft.com/. Additionally, they promised that the .NET Framework source code debugging will finally work in Visual Studio. At almost the same time JetBrains published EAP of its dotPeek tool with some great features that make “reverse-engineered debugging” extremely easy. And for other DLLs we still have the old Microsoft Public Symbols server. In this post I am going to show you how I configure my system and Visual Studio for different debugging scenarios.
pdb
PDB files out of the debugger
I suppose that I don’t need to stress how important it is to have valid PDB files while debugging. Normally the PDB files are silently loaded by the debugger and you are happy to see all the symbols resolved in your modules window. Unfortunately you may also run into situation when the debugger will not be able to find matching symbols. The reason may be as trivial as a broken Internet connection or much more complicated like mismatched signatures. In this post I’m going to show you how to check your symbol files before debugging as well as how to extract the source file information from them. As there are different ways (and tools) to manipulate the symbol files I will present the ones that I am aware of, but feel free to leave comments about tools that I might have missed and I will try to update the post.
Forget PowerPoint – make a slideshow in… a debugger :)
Few days ago I had a presentation in the Warsaw .NET Group about PDB files. To make the slideshow more attractive (or rather original:)) I decided to replace the PowerPoint with something more connected with the subject, such as… the Visual Studio debugger. The only question was how to actually achieve this. The idea grew in my head after reading a brilliant Mike Stall’s post about debugging dynamically generated code. Mike shows in it how to emit sequence points for a text file of your choice and so bind this file with the generated MSIL. If done correctly, the debugger will load the text file, allowing you to step through its content and at the same time execute the emitted MSIL. So what if we could use the presentation table of contents as our source file and for each title (line of the table of contents) emit MSIL which will present a corresponding slide in the console window? This will actually make the debugger play the role of the PowerPoint:)
Debugging NHibernate: prepare symbol files
To be able to debug the NHibernate source code the debugger must know how to find it. If you are using the 3.0.0 version of NHibernate you may use http://www.symbolsource.org configuring Visual Studio to use their symbol store. If your NHibernate version is different you need to either compile NHibernate on your own and reference the produced binaries in your application build process or make use of the sourcepack script. Here I will describe the second approach (especially because I’m the author of the sourcepack and I need to advertise it somehow ;)).
Continue reading
Sourcepack released
Yesterday I released a first version of sourcepack. The sourcepack is a powershell script which examines and then modifies the PDB files in the given directory to make them reference the source code archive file. It may be considered as just another tool for indexing the PDB files which uses the archive file (zip, 7z or any other) as a source code repository. So the extract operation will simply consists of calling one of the packer applications (currently 7za.exe) with correct arguments.The processed PDB files may be then copied to the symbols directory (configured in your debugger) and the debugger will seamlessly extract the source files that are needed for you to debug the library code.
Enough said, if you are interested in sourcepack you may get it here. Some documentation is available here.
Debug notes 