Thursday, October 27, 2005 9:51 AM
If you are a coder, then you probably spend a fair amount of time debugging code (otherwise, I'd love to hear from you!). The “old“ way is to add lots of console print statements to display what the application is doing at a given time. Of course this requires changes to code, and if you decide to change what information prints out you may need to restart the app (though this works much better in VS 2005 to begin with). At the end, all of the print statements need to be removed (hope you didn't miss any!).
Instead of simple print statements, many people use logging API's to dump out information at the lowest priority levels (DEBUG or INFO). The reasoning is, you can add them for debugging, disable them in configuration, and you can deploy without removing them with little to no overhead when not used. This doesn't help with the need to modify the statements as you troubleshoot though, and often the need to print something is transient and makes no sense to retain through deployment.
Yet another option is to add breakpoints to trouble spots. When the breakpoint fires, view the state of the variables or expressions in question. With Visual Studio 2005, you can mouse over values and expressions, expand/collapse properties, use the Quick Trace window, or the Immediate window. Lots of great options, but unfortunately the act of stopping the code in order to do this often wrecks the flow and you don't get to spot what you are trying to see. There's a famous axim about this... you can't observe without changing... or something like that.
What about another option? How about don't add any method call to your code. Just tell the debugger to print the information you need when it hits certain points in code. Nothing ever gets embedded in the executable, and you can deploy the same code you debug. You can do this. It's called Tracepoints.
- First of all, locate the line of code where you want to examine something
- Click in the left margin to add a breakpoint.
- Right-click that breakpoint, then click When Hit
- Alternate: replace steps 2 & 3 with Right-click the line of code, then click Breakpoint | Insert Tracepoint.
- Select Print a message or Run a macro.
- Check Continue execution.
Step 6 is the key. After it prints the message or runs the macro, it just keeps going. If you add a Tracepoint within a loop, you'll see statements pile up in your Output Window. Very handy!
You can use the special keywords like $ADDRESS or $CALLSTACK, but I really like the ability to evaluate any expression using curly braces. For instance, entering:
The length is {Path.GetFileName(fileName).Length}
will display “The length is 5“ when run. It's an awesome feature, and definitely worth checking out! I don't know if it's a new feature for 2005, but it's definitely my new favorite feature!
UPDATE: I checked Visual Studio 2003, and it does not appear to have been available. Looking back at breakpoints in 2003, they seem really primitive now!