Tuesday, July 24, 2007

Breakpoints in ASP.NET development

1. Modes:
A. Design: Write your code
B. Break: Step through code (F11)
1. Can NOT change code during break
C. Run: Full speed… (F5)
2. Note that these notes use the default keyboard setup.
3. How to:
A. Right click in Solution Explorer and set a start project and start page.
1. No matter what page you are on the start page starts the session
B. Open page and set a break point
1. Double click on the left margin of the line to break on.
C. Press F5 (bring it alive!) or Debug.Start
D. Execution will stop at the breakpoint
1. F11 to step line by line.
2. F5 for back to full speed
E. Debug . Stop to stop debugging..
4. Breakpoints
A. Are saved with code…
B. Click in left margin space.
1. Can disable breakpoints….
2. Right click, Breakpoint properties
3. Condition…can break just when a specific condition is met
a) Like a variable changes
4. Hit count for running through code a limited number of times
a) Iteration testing
5. Moving the executing point
A. While in debug…run to cursor
B. Or drag the yellow arrow
C. Step Over if you are sitting on a call to a long sub you know that works…
6. Values of variables
A. Hover mouse over var AFTER it’s value is set.
B. In Break Mode right click on variable and
1. Quick Watch and / Add to Watch Window
2. Watch Window lists all the vars you are tracking….
C. Good tip…leave the autos window open…shows all your variables.
1. Ctrl Alt V + A (values = View Auto windows)
7. Best tip: Immediate Window: Ctrl Alt I
A. ? strName prints the value in strName
B. strName = “Larry” sets the value of strName.
C. You can enter almost any run able code and test if it will work before it blows up and you have to start over.
8. Call Stack…
A. Dark lines are your code…double click and you are on it.
B. Grey lines are VB.NET’s own code to get here.
9. Command / Immediate Window: Ctrl G
A. Type and run code
1. No Intellisense in .NET orginal…YES in 2003
B. Change variables strDemo=”Larry”
C. ? means print result….?Now
10. Other Debug Windows
1. Locals Window: Lots of information…maybe too much for most.
B. Autos…is just the locals window with only the variables.
C. Many others…will use them as we need them
1. Modules…what dlls’ are loaded and what version.
2. Disassembly…what the assembly language looks like.
11. Working with System.Diagnostics.Debug Class
1. System.Diagnostics.Debug.WriteLine("Debug.WriteLine")
B. Or Use Imports System.Diagnostics at top
1. Debug.WriteLine(“text”)
C. Writes to the Output window (not the immediate window)
1. Output window is consider a “listener”
2. If you dig into the Debug & Trace class you can create your own “listener” objects such as files.
12. Debug.Assert: Coded conditional breakpoint….
A. Debug.Assert(decDemo <> 100")

This will get displayed in Output window if decDemo is less than 100
---- Assert Short Message ----
Number must be > 100
B. Why? Allows you to check values sent to a procedure are really what you think what they are….
C. Debug.WriteLine…writes to the Output window…
13. Conditional Compilation
A. Directives = #If …. Then … #else #end if
1. Tell the compiler if the code should be left in.
2. Note VS does an auto left justify
B. Compiler Constant…place at the top of the page.
1. Constant MYDEBUG = True
2. Then in your code put
Response.Write("Debug On
Response.Write("Debug Off
#End If
C. Using built in constants Debug and Trace
1. Build . Configuration Manager . Change Active state from Debug to Release….and the Debug constant becomes false
D. Creating a Global Constant that can be used throughout your application
1. Why…so you don’t have to redefine on all pages
2. Right click on Project . Configuration . Build . Custom Constants
a) In addition to your own…note the default DEBUG and TRACE constants
(1) These are defined by Build.Configuration . Current Configuartion.
3. Custom Constants you can define your own constant and set it to a value
a) MyTest=True.
b) Where ever you #If MyTest it will always be true…..
(1) Until you change it…..instantly all that code is removed from the compile.