It is widely known that the in the software development process testing and debugging take much more time than actually writing the lines code. Some pessimistic articles talk about a ratio of up to 80% to 20% (debugging and test vs. code writing).
This is a very strong reason to get down and dirty to get to know the tools we are working with. Because in many cases the debugging activity is very long and without any fixed forecast of it's end exploring hidden features of the Visual Studio debugger can save you allot of time.
Did it ever happen to you that you had a large dataset, and while processing each row you get an exception, or a calculation is wrong (but only for specific rows). I used to set a breakpoint to the specific line I wanted to investigate and ran the solution. And then, because the record set is very large I pushed F5 allot and (to be frank) I missed the desired spot a few times because I was getting too enthusiastic about leaping over records that were of no interest for me.
The next approach was to write some code to check if I am at the desired record, where I set my breakpoint so the debugger stopped only at the specific point I was interested in. But this needed writing new code, which is not elegant at all. Another approach was to write a “logger” which would export the data I was interested in, and after a successful run, I went to the saved log file and inspected the outcomes. Again not elegant at all!
As a demonstration I will use this piece of code which resembles somehow looping through a big set of data.
protected void Page_Load(object sender, EventArgs e)
for (int i = 0; i < 100; i++)
Response.Write(i + " ");
Tip 1. – Breakpoint Condition
If you know you need to stop where your counter is 60 there’s no more need to write custom code. The Visual Studio Debugger lets you specify a condition, so if and only if that condition is satisfied will de debugger stop. I.E.: even if the breakpoint is set … it will jump over that.
To achieve this you should put the breakpoint on the line of code you wish your debugger to stop and right-click the red dot at the margin of your line. A little context menu shows up and select: “Condition…”.
Top stop at the 60th count simply set the condition to what you would normally write in an if clause: i==60 :
Now if you run your application the debugger will only stop when i reaches 60. There is also another interesting case where you would like to debug and check your intermediate value in your watch. For example if you would like to check your values in every 5th loop your condition would look like:
Tip 2. – Breakpoint Hit Count
Top keep track of how many times the debugger has stopped at one of your breakpoints, you have to option to look at “Hit Count”. There is also the possibility to choose when the debugger should stop at your breakpoint: always, when the hit count is equal to a specified number, when the hit count is a multiple of a specified number or when the hit count is greater than or equal to a specified number.
Tip 3. – Breakpoint Filter
You can restrict the breakpoint to only being set in certain processes or threads. This is extremely useful if you develop multithreading applications. It will definitely shorten your debugging experience by miles!
And a personal favorite …
Tip 4. – When breakpoint is hit
You can specify what to do when a breakpoint is hit. The particularly useful thing is that you can run Macros when the breakpoint is hit. An extensive list of what macros there are available ready made can be found of MSDN – Macro Samples.
I’ve been using these features for a while now and I can guarantee hand on heart they are real time savers.