# Saturday, 06 September 2008

Imagine you have a bug that happens only in production. You connect to the production server and do a whole pile of exploring, and now you think you know what you need to tweak on your dev box to reproduce the problem and get started on fixing it. Or perhaps you are half way through figuring something out on your own machine and you need to hand over to another developer. Maybe you just want to switch to your laptop because you’re leaving the office. There are many reasons why you might want to copy breakpoints between computers. As you may know, they are kept in a .SUO file (Solution User Options I believe) in your solution folder.

But heavens above, do not try to copy that file from one machine to another! As John Robbins says:

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!"

So John took care of this with his own add-in. You can save a set of breakpoints into a little file. You can then move the file between machines and use it to set all those same breakpoints on another machine. Or, probably even more fun, you can set aside the 20-some breakpoints, tracepoints, conditionals and so on that you painstakingly set up for bug A, save them and then clear them all, set different ones for the drop-everything-urgent bug B, and then when B is fixed you can get all your old breakpoints back and return to working on A. John is giving the add-in away, it works for both native and managed code, so go on, get it now.

Kate

Saturday, 06 September 2008 10:01:09 (Eastern Daylight Time, UTC-04:00)  #