So there I was knee deep in a great debugging challenge. On one machine, I had set up somewhere around 15 advanced breakpoints that had all sorts of properties set such as conditionals, hit counts, and so on. As I was feeling like I was getting close to the bug, I wanted to set up an identical debugging session with those breakpoints on another machine. While I could have manually recreated all those advanced breakpoints, I tried to cheat. Your breakpoints, along with Watch window variables, window layout, and other session state items are stored in a hidden file, <Solution Name>.SUO. I copied that file over to the other machine and opened the solution file. Visual Studio promptly crashed.
The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it’s the .SUO file’s fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is “Delete the .SUO!” When it comes to Visual Studio hygiene, deleting the .SUO file is right up there with cancer screenings.
As I am tired of manually setting my breakpoints again on other machines and sick of the .SUO corruption bug I decided to solve it once and for all. I wrote a Visual Studio 2008 add-in, Debugger Settings, which makes it easy to save and restore your solution’s breakpoints. It also makes it easy to create and apply different breakpoint sets on a solution, which is something I’ve wanted in Visual Studio for a long time. You can download the code for Debugger Settings here.
Debugger Settings is at version 1.0 and I would love to hear your feedback. Please note that I’ve only done my testing on Visual Studio Team Suite, but Professional Edition and above should have no trouble. Debugger Settings will not work with the Expression versions as they do not support extensibility.
Debugger Settings currently only saves and restores breakpoints but does work with both .NET and native C++ projects. I would love to be able to get and set the Watch window variables, but it does not look like that can be done without extensive reverse engineering. However, if there’s enough demand, I might be persuaded to give it a go. Another feature I’d like to add is the ability to save and restore custom Exceptions added to the debugger’s Exception dialog. Please let me know if you have other features or find problems.
Installing Debugger Settings
- After downloading the zipped code, unzip it keeping the directory structure intact.
- You may not need to do this step, but I’ve always had problems with Visual Studio not loading my add-ins correctly if I put them in the defalt DocumentsVisual Studio 2008AddIns directory. That may be because I’ve got my Documents directory in a domain redirected folder. If you get a FileNotFoundException with a code of 0x80131047 attempting to load Debugger Settings, you’ll want to add the <unzip dir>DebuggerSettingsDebug directory to the Add-in file paths by going to the Options dialog, Environment, Add-in/Macros Security dialog:
- Because Visual Studio has a problem finding assemblies in the same directory as the .AddIn file, you’ll need to edit <unzip dir>DebuggerSettingsDebugDebuggerSettings.AddIn and in the Assembly elements, enter the complete path to DebuggerSettings.DLL.
- Restart Visual Studio.
Using Debugger Settings
Debugger Settings works mainly in the background, but you can set its options in the Options dialog.
By default, Debugger Settings will save any breakpoints you have set when you close a solution to a .DebuggerSettings file in the same directory as the solution. When you open a solution, Debugger Settings will look for the .DebuggerSettings file and reset any breakpoints that were not set from an existing .SUO file.
Debugger Settings adds four commands to the IDE, which should be self explanatory:
- DebuggerSettings.RestoreFromFile
- DebuggerSettings.RestoreSolution
- DebuggerSettings.SaveToFile
- DebuggerSettings.SaveSolution
As an example, to save a set of breakpoints to a named file, you’ll go to the Command window and execute the DebuggerSettings.SaveToFile command. If you don’t specify a filename as the parameter to the command, you’ll be prompted for the filename with the File Save dialog.
There are four types of breakpoints that Visual Studio supports: file, function, address, and data (for native C++ development). My original intent was to support all the breakpoint types, but when you attempt to set an address or data breakpoint through the Visual Studio automation model, the breakpoint is immediately set to disabled. Hopefully a future version of Visual Studio will let us automate setting those two breakpoints. The good news is that file and function breakpoints are the huge majority of breakpoints. I implemented the work to set address and data breakpoints in case this gets fixed in the upcoming Visual Studio 2008 Service Pack 1.
One other limitation of the Visual Studio automation model is that there’s no way to know if a Tracepoint has the message disabled. The Breakpoint2.Message property is always set to the default string value. Thus, if you have a Tracepoint set to execute a macro, but not output the trace string, as shown below, Debugger Settings will enable the Print a message checkbox simply by setting the Message property.
Wrap up
The implementation of Debugger Settings is very straight forward. The only moderately interesting technique I used was to work around the fact that the Breakpoints.Add method does not support setting Tracepoints directly. Visual Studio’s code metrics reports only 467 lines of code so far in Debugger Settings. If I can figure out how to get the Watch window variables, I’m sure the code size will grow exponentially.
Let me know either in comments to this entry or through email (john at this company’s domain) if you find Debugger Settings helpful or find problems. Also, any feature requests strongly considered.