How to force debugger to skip a piece of code? - c#

There is huge amount of code in my project which already debugged 50% of it.
Every time I try to debug it I have to manually set breakpoints after unwanted piece of code to skip it.
Is there a way to tell debugger not to debug that part of code ?
Any extension for this ?
Let's face debugger is on line 1500.
Method1(){
Line 1500 CODE
Line 1501 CODE
...
Line 1726 CODE
Line 1727 CODE
...
Line 2200 CODE
}
I won't need to debug lines between 1727 and 2200.
NOTE : It's not just one piece. Otherwise I would be fine with manual breakpoints

Don't know why it's not in the answer but you can set next statement by CTRL+SHIFT+F10 or dragging the yellow arrow to wanted line and code before next statement will not be executed.
Found it here

If the code in question is encapsulated in a method, you can skip the method by applying the DebuggerStepThroughAttribute on it.
Other than that, setting breakpoints is how to do it.
So, extract this code into a method and apply the attribute to it ;)

You can also click on the line you want to skip to and hit Ctrl+F10 (Run to Cursor). It will jump directly to that line.

Related

Debug statement execution counter

Is there a way to get statements execution counter in Visual Studio in C#?
So that when I encounter a bug after long digging into code with debugger, with many loops, and I want to step into function that caused the problem and I already went past it with debugger. So I could put this line before the problematic function:
if (Global_execution_counter == 5484984)
int d = 0; // put debug breakpoint here
execute_problematic_function (); // wanna step into this function
Yes you can and without any global variable counter.
The solution is using a hit count breakpoint.
Set a breakpoint at execute_problematic_function ();; right click it to bring up the context menu:
Then click "Conditions", select "Hit count" and set it to whatever value you want.
If you still don't know what's the hit count that you need to set the breakpoint to, you can take advantage of the breakpoints window, which will tell you the current value of the breakpoint:

Can I set a breakpoint in an inline if in Visual Studio and C#?

Can I set a breakpoint like below (the asterisk symbolises the breakpoint dot)?
var x = ifThis ?
* This() :
That() ;
Environment is C# and Visual Studio 2015.
(I just told a colleague that I was possible but seem to stand corrected)
You can only place the breakpoint in the whole line.
However, you can:
Press F11 while debugging to enter the line and see which function was hit;
Add a conditional breakpoint so it will only break in the specified conditional; This is the closest to what you want, and have no practical difference on setting the break point on only one part of the expression, other than the full line being marked in VS.
To add a conditional breakpoint, first set the breakpoint, then right click the red dot on the left -> "Condition..."
Visual Studio sees this as a single line and the breakpoint will show as being on all 3 lines. You cannot set it on a single line in an inline if statement.
Sorry!
Karl and Andre are right. In VS 2015 you can only use the conditional Breakpoint and then step into with F11.

Solutions or workaound for Visual Studio conditional breakpoint slowness

I'm using a conditional breakpoint to determine when a C# DateTime variable is greater than a certain time. This breakpoint will be checked approximately 50,000 times in a run.
my conditional breakpoint looks like:
quote.Time > new DateTime(2014,2,4,3,59,0)
Without this conditional break point my test run takes about 15 seconds. With the conditional breakpoint it takes 45 minutes.
Is there anything I can do to help speed this without modifying the code I'm debugging to add an assert or conditional?
Is there anyway to make it calculate the DateTime variable only once? Or is this more of an architectural issue with how conditional breakpoints are implemented in the IDE?
why don't you stop using a conditional break point and change the code until you have debugged it. so the code would become something like:
int dummyx = 0;
if (quote.Time > new DateTime (2014,2,4,3,59,0 )
{
dummyx++; // put normal break point here!
}
This will run much faster.
Just for debugging purposes I'd say create a new if-statement and a dummy variable (like int i = 0;) and set the breakpoint on that line. Then just step into / step through the rest of the code.. Just for testing, you can always just remove those 1-2 lines of code after testing.
The if-statement (logically) containing:
if (quote.Time > new DateTime(2014,2,4,3,59,0)) { int i=0; }
Evidently conditional break points being very slow is a known issue. See: http://www.bing.com/search?setmkt=en-US&q=visual+studio+conditional+breakpoint+slow
Since I know how many times my function will be called, deterministic simulation, I ended up using visual studio's Hit Count breakpoint feature.
This allowed me to not have to hack up the code with an if statement and iterate faster if my break condition changed.

Return from a function using a breakpoint

Is it possible to automatically return from a function using a Breakpoint/Tracepoint?
I don't want to drag the execution point or set it with CTRL+SHIFT+F10 every time the breakpoint is hit.
I tried "printing" the following "messages" When Hit, but the executions continue without change.
{return;}
{return null;}
Note that I need to return from the function without actually changing code.
To clarify what a Tracepoint is: "A tracepoint is a breakpoint with a custom action associated with it. When a tracepoint is hit, the debugger performs the specified tracepoint action instead of, or in addition to, breaking program execution." From MSDN.
If you don't know what I mean with "printing messages", you might want to read this AltDevBlogADay post about Tracepoints. It's good.
In Visual Studio you could just drag the arrow, that indicates the current code line while debugging, to the end of the function.
Okay, after a bit of digging around you can do this - but it's not going to work in all cases.
Beware, this uses macros and can't be guaranteed to work with inline delegates; or with methods that actually need to return something. It automates the process described by #juergen d and #Erno when a breakpoint is hit; using very simple heuristics to find where the end of the current function is.
You first need to add this macro to your macros environment (open with ALT+F11 in VS). This code is probably not as good as it could be as I've just rushed it out :)
Sub ExitStack()
'get the last-hit breakpoint
Dim breakPoint As EnvDTE.Breakpoint
breakPoint = DTE.Debugger.BreakpointLastHit()
'if the currently open file is the same as where the breakpoint is set
'(could search and open it, but the debugger *should* already have done that)
If (DTE.ActiveDocument.FullName = breakPoint.File) Then
Dim selection As EnvDTE.TextSelection = DTE.ActiveDocument.Selection
Dim editPoint As EnvDTE.EditPoint
'move the cursor to where the breakpoint is actually defined
selection.MoveToLineAndOffset(breakPoint.FileLine, breakPoint.FileColumn)
Dim codeElement As EnvDTE.CodeElement
codeElement = DTE.ActiveDocument.ProjectItem.FileCodeModel.CodeElementFromPoint(selection.ActivePoint, vsCMElement.vsCMElementFunction)
'if a function is found, move the cursor to the last character of it
If Not (codeElement Is Nothing) Then
Dim lastLine As EnvDTE.TextPoint
lastLine = codeElement.GetEndPoint()
selection.MoveToPoint(lastLine)
selection.StartOfLine(vsStartOfLineOptions.vsStartOfLineOptionsFirstText)
'execute the SetNextStatement command.
'Has to be done via ExecuteCommand
DTE.ExecuteCommand("Debug.SetNextStatement")
End If
End If
End Sub
With that in place, now you can set your breakpoint - right click on it and hit the When hit... menu option (this only works in VS2010 I believe). ScottGu describes this in this blog post.
From the dialog, find the ExitStack macro that you've just pasted in.
Run the code with the debugger attached and when the breakpoint is hit the rest of the function's code should be skipped. This should obey other debugger tricks - like conditions etc.
Note - I used this SO to solve a problem I was having; originally I was invoking the debugger's SetNextStatement method directly and it didn't work
I have no idea how methods that should return will behave - in theory they should return whatever the return value local is at the time, but in some cases the fact is this simply won't work!
Equally if the breakpoint is in a try/catch block then it won't work - because the try/catch has to be exited before you can set the next statement to somewhere outside of it.
Two options:
If you want the function to complete its execution and break after returning to the caller. Press "Step Out" (Shift-F11)
If you want to skip the execution of several lines, drag the yellow marker to the next line you want to execute. Remember, dragging the marker to a location might cause an order of execution that can never happen when running without interfering so the result might be completely wrong.
Yes, you can do this directly using a tracepoint.
Find the address of the return statement at the bottom of the function by breaking on it once, and then looking at the EIP register either in the Registers window or add a Watch for "#eip".
Add a tracepoint to the line you want to jump from. Remember that the jump will occur before anything on the line is executed. The content of the tracepoint should be {#eip = address} using the address from step 1.
Profit!
See also https://stackoverflow.com/a/14695736/301729

How do i check the value of Array[x,y] quickly when debugging?

When a breakpoint is hit, I could easily hover over a variable to see its current value. But when an array is present this becomes tricky (at least for me)
dsInfo.Tables[0].Rows[0]["IsApproved"]
There are few things that I could actually do in this scenario to quickly check the value.
Debug.WriteLine()
MessageBox (lame!)
Breakpoint -> When Hit -> Print a Message
Swim through the array to the find the position.
Are there any better methods to check the value of Array[x,y] quickly using Visual Studio?
You can copy expression you want to check (dsInfo.Tables[0].Rows[0]["IsApproved"]) and paste into 'Watch' window when debugging.
Hope this helps
You can type in the variable name/expression dsInfo.Tables[0].Rows[0]["IsApproved"]
into the Immediate window (Ctrl+I) while debugging.

Categories