Geschreven door Herman Cordes - 17 maart 2017
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?
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.
Take a look at the following code sample. The sample is reading and deserializing lines from a text file into memory.
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).
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?
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.
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.
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.
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.
Herman Cordes is Craft Expert van Team .NET binnen Craft, hét groeiprogramma voor IT'ers (powered by Centric). Wil je zijn blog volgen? Schrijf je in voor de Craft-update.
Choose your language Kies uw taal Choisissez votre langue