Centric connect.engage.succeed

Debugging with Visual Studio - Part I: Breakpoints

Geschreven door Redactie Craft - 17 maart 2017

Redactie Craft
Debugging… an unavoidable part of software development. Somehow it seems (nearly) impossible for a newly built application to run error-free when starting for the first time. This is the stage to analyse your application and fix the errors. Visual Studio has some nice tricks to help you with this process. Let’s review a few of these features in this first of a series of blogs on debugging.

In this first part we'll start off with the most obvious one, setting breakpoints in your code. Everyone has clicked the editor’s margin to add, remove or disable breakpoints. But did you know there are some nice tricks you can do with breakpoints?

Breakpoints window

First let’s review the Breakpoint window. In some cases, it can be useful to list and manage all breakpoints in your solution. The window can be activated in Visual Studio by using the menu Debug > Windows > Breakpoints. You’ll see something like the picture below. From here it’s also possible to label breakpoints, or even import and export them.

Breakpoints window

Breakpoint conditions

Take a look at the following code sample. The sample is reading and deserializing lines from a text file into memory.

Method overview

Let’s imagine we’ve got a bug report describing data containing the word ‘cheesecake’, which does not get deserialized. In cases like this I don’t really like to debug manually by stepping through the entire for-loop; who does? Breakpoint conditions come to the rescue! Place a breakpoint at line 35, right click the breakpoint icon (red dot) and choose ‘Conditions…’ to configure it to break only when meeting the specified condition. Alternatively, you could go to the breakpoints window to add a breakpoint, which also gives you the option of changing the column where you want to add a breakpoint (e.g., to use within for-loops).

Breakpoint conditions

Just put any line of C# code here which returns a Boolean value. By default, the condition is configured using a ‘Conditional Expression’ to break when the condition ‘Is true’.

Did you know, though, that you can also use this feature to do any of the following?

  • Break only every nth time: use ‘Hit count’ for the first combo and ‘Is a multiple of’ for the second and type in your number in the textbox.
  • Break only when a certain variable has changed: use ‘Conditional Expression’ with ‘When changed’ and fill out your variable.
  • Break only when a certain thread is running: use ‘Filter’ with ‘Is true’ with ‘ThreadName = "your-thread-name".
  • And, of course, combine various conditions all you like!

Notice that the debugger icon has changed from a solid red dot to a red dot containing a white plus sign. This makes visually clear that a breakpoint does not break on every occasion.

Breakpoint actions

When reviewing the code sample in the first illustration, we can see that a few debugging lines are reporting the line number being read to the trace listener. The same can be achieved using debugger actions. Notice how debug conditions and actions can be combined. Also notice the debugger icon has changed from a dot to a diamond. Again, just type any line of C# code, but this time return it as a string.

Breakpoint actions

Run To Cursor

The last feature of the day can be used when you want to jump right in, without setting a new breakpoint. Right click a line of code and select ‘Run To Cursor’. This feature sets a one-time use breakpoint, fires up the application and takes you directly to the place you want to be. Be aware that this will only work if the default code path takes you to the selected line and you won’t be hitting any other breakpoints on the way.

Run to cursor

Wrap up

These are just a few ways to have a look under the hood of your application. How do you feel about these features? Do you use them often, or do you know some other tricks? I’d love to hear about it.

Next time in this series we’ll start the debugger and review some Visual Studio features which are only available during an active debugger session.

Also read: Debugging with Visual Studio - Part II: inspection and intervention.


Schrijf een reactie
  • Captcha image
  • Verzenden