Scott Dorman

ephemeral segment

  Home  |   Contact  |   Syndication    |   Login
  608 Posts | 11 Stories | 900 Comments | 51 Trackbacks

News


Post Categories

Image Galleries


Microsoft Store


Creative Commons License



Locations of visitors to this page

Subscribers to this feed

TwitterCounter for @sdorman

View blog authority

Add to Technorati Favorites

Windows Live Alerts

AddThis Social Bookmark Button

LinkedIn profile

Community Credit profile

The Code Project

Follow me on Twitter

Get Free Shots from Snap.com

Community Credit Hall of Fame

Get Feedghost

Xobni outlook add-in for your inbox



Support This Site

Tag Cloud


Article Categories

Archives

Post Categories

Image Galleries

We have talked about the Location, Condition, Hit Count, and Filter modifiers for breakpoints which only leaves the When Hit modifier. Using the When Hit modifier allows you to change your breakpoint to a tracepoint.

What is a tracepoint? Simply put, it is a breakpoint that continues execution. Why would this be interesting or even important? Tracepoints are great when you want to trace a particular path of execution, such as OnDeserialized events in your WCF DataContract classes. You are interested in watching the order your objects are deserialized to ensure that everything is happening when you expected it to occur.

In this scenario, you aren’t really interested in stopping the execution. Ordinarily you could achieve this by inserting Trace.WriteLine (or even Console.WriteLine or Debug.WriteLine) calls throughout your code. While this would work it means that you are adding lines of code just for debugging purposes (so hopefully they would only be needed temporarily) which means you need to remember to remove them when you are done debugging. Wouldn’t it be great if you could simply set a breakpoint to execute Console.WriteLine (or some equivalent) to display a message in our Output window?

That’s exactly what a tracepoint does, but it can do a lot more than just that. 

image

The When Breakpoint Is Hit dialog allows you to simply print a message, but that message can contain special keywords and can also evaluate methods and properties of any object that is in scope when the tracepoint is hit. In addition to printing a message,  you can also run a macro. By default a tracepoint is intended to continue execution, but you can change that as well which will effectively give you a breakpoint which will print a message and/or execute a macro before breaking.

Technorati Tags: , ,
DotNetKicks Image
posted on Saturday, February 14, 2009 4:17 PM

Feedback

# re: Visual Studio 2008 Debugging Tricks – Tracepoints 2/18/2009 10:45 AM The_Tosh
It took me a couple of tries to get the value of a variable to print out. The trick is NOT to escape the curly braces when you want to evaluate variables.

Sample: DateTime DateOfBirth;

Function: $FUNCTION, This person was born in month {DateOfBirth.Month}

And the message gets printed to the Output Window.

# re: Visual Studio 2008 Debugging Tricks – Tracepoints 5/25/2009 12:52 AM MQ
Using VS2008 tried "When Breakpoint Is Hit" feature as described in this article. The diamond shaped breakpoints were stopping fine, but did not print messages or value of a variable in the Output window. What could be wrong?
MQ

# re: Visual Studio 2008 Debugging Tricks – Tracepoints 10/21/2009 6:49 AM Ruth
There is a setting in the Options that redirects debugger output to the immediate window... only in my experience it gets redirected to /dev/null.

Post A Comment
Title:
Name:
Email:
Website:
Comment:
Verification: