Given the code
[Test]
public void Test1()
{
var a = new A();
a
.Method1()
.Method2();
}
is it possible to set a breakpoint so that execution pauses after Method1() has executed, but before Method2 without going to the definition of Method2 and putting a breakpoint there? When I do it, the breakpoint appears at the 'a'.
you can't set a breakpoint there, but you can set your breakpoint on the whole statement, and then use the "Step into Specific >" command on the right-click menu (Debug.StepIntoSpecific) to step into Method2().
you can also do repeated step in/step out to step through the indivdual method calls of the compound statement.
Use Rider instead of Visual Studio. IntelliJ Idea is capable of logical step in when fluent syntax is used. It is 2017 and fluent syntax is everywhere (LINQ). Shame on Visual Studio (even 2017).
No, the debugger's unit of executable code is a statement. There are only two in the method body in your snippet. Post feature requests to connect.microsoft.com. It's going to be a hard sell, it is not technically impossible but a potentially heavy re-engineering effort.
Related
Is there a way to perform the opposite of the "Extract Method" refactor in Visual Studio?
I have a legacy codebase that has ~50 very short, private functions that are only used once each, and I have been tasked with inlining them.
If an automatic inline refactoring isn't possible, is it possible to reduce the amount of time it takes to inline these function calls? My current workflow is:
Copy the code in the function.
Find where it is called.
Replace the function call with the copied code.
Replace local variable names from the function.
Delete the function.
The refactoring you are looking for is called "Inline Method".
While Visual Studio does not provide this refactoring out of the box, you can get access to it (and many other useful refactorings) by installing the Jetbrains ReSharper extension for Visual Studio.
With the extension installed, all you need to do is click on the method declaration or method call, and invoke the 'Inline Method' refactoring. This will automatically inline all occurrences of the method and delete it.
You might consider collecting the functions into a header file and decorating them with inline. I realize this is not exactly an answer to what you asked, but may be a better solution to your problem because this way the compiler would perform the inlining (if it sees fit).
It depends on the situation, but keeping the function definitions might lead to clearer code, thus might be of value even if called only once.
This is also quicker and less error prone than manual "inline method" refactorings.
I have a code base with mixed Java and Groovy code. For iteration in the Groovy code, we tend to use closures:
String[] strings = ["First", "Second", "Third"]
strings.each { string ->
println string
}
When I debug this in IntelliJ IDEA (v. 11) by stepping one row at a time, the code executing in strings.each() (that is println string) is stepped over. I can put a breakpoint at the println row, and I will be able to debug it, but it is a little workaround that would be nice to avoid.
Is there a way to configure intelliJ to not step over Groovy closures? There are no applicable options in File->Settings->Debugger->Groovy.
Edit:
To clarify what I expect intelliJ to do:
Say I have a Java style iteration like this:
for (String string : strings) {
println string
}
If I use "Step over", the debugger steps into the iteration with no problems. I can the continue "stepping over" and still be in the loop until there are no more objects to iterate over. This is what I would expect for closures like above to.
It might not be a problem in a case with one or two closures where you manually have to set breakpoints. But if there are many, it would be really neat to "automatically" step into them.
I fully agree that there needs to be better Closure debugging support in IntelliJ, since what you are asking to do is not always as straightforward as it should be without jumping through some hoops.
Like you've found, you can put a breakpoint on the println row, which will usually let you break within the Closure (but not always). Once you have a breakpoint, IntelliJ has a pretty powerful Conditional Breakpoint system, which will let you have much better control over when to break.
Another route I've found useful from time to time is to take everything in these closures and toss it into a method that the closure calls, instead of having the code in the closure directly. This doesn't change the runtime behavior too much, and I've found that it gives me much more control over things. It also usually is an indication that I need to refactor as well, since it's already too painful to dig into that code.
I don't know that the following piece of code is really relevant, but for the sake of full disclosure here is the code I was trying to call from the Immediate Window:
abstract class Test
{
public int x;
public Test()
{
x = 5;
}
}
class TestImp : Test
{
public int GetX()
{
return this.x;
}
}
It was just a test to see whether the default base constructor gets called automatically or if I have to call it specifically because I couldn't remember.
Okay, on to the problem. I typed this into the Immediate Window to see the result:
new Mercury_Reports.TestImp().GetX();
And rather than evaluating the expression it just started my application. I closed the app and tried again two more times and got the same result. The next time, I went and put a breakpoint in my Program.cs file. Then instead of starting the app like it did the last three times and then hitting the breakpoint, it decided to actually just evaluate my expression.
I've seen some weird things in the Visual Studio IDE before, but I think this is one of the weirdest. Anyone have a clue as to what was going on there? :)
When evaluating an expression in the immediate window when you're not debugging the following process takes place
Loads your project / application binaries into the hosting process
Silently attaches the debugger to the hosting process
Evaluating the expression against that debugger session
Most of the time this is done in a way that makes it hard to detect that the application is actually being run. But occasionally a side effect of the application shows through and reveals what's really going on under the hood.
EDIT
In general it shouldn't be displaying the UI though. I can think of some obscure corner cases where this would happen though and not be a Visual Studio bug. The basically all come down to the same scenario though
The evaluated string causes an unintended side effect to happen at a time where it wouldn't happen during normal program flow.
This is actually more common than you'd expect in the immediate window because it's essentially executing your code out of order. Normally you'd never get to new Mercury_Reports before executing Program.Main but in the immediate window this is exactly what happens. This can have nasty effects like re-ordering static type constructors
Here are some unintended consequences which can surface via an immediate window expression
Cause types to be loaded and hence cause their static initializers to run
Change the order in which static initializers are run
The return type of the expression has a ToString method the debugger executes
The return type of the expression has a DebuggerDisplay value which the debugger executes
In the past I have seen the static constructor case cause UI to show. Essentially a static type constructor was evaluating MainForm.Instance (a lazy creation property). During normal program flow it was called from Program.Main was run and from then on was simply available. In the immediate window though Program.Main didn't run. But the expression being executed inadventently loaded that type and hence displayed the UI for what was a trivial property getter.
This is a pretty obscure corner case though. I'd say the most likely cause here is a bug in Visual Studio. Debugging is nasty business, especially when executing live code, and this is probably a symptom of that.
You know how you can click the yellow arrow on a breakpoint and drag it down to skip execution of lines of code? Well, is it possible to create a "When Hit" macro (or something similar) that skips execution of the line containing the breakpoint?
So instead of writing code like
if(!Debugging)
Response.Redirect("LoginFail.aspx");
I could sit a breakpoint on the Response.Redirect() line and "When Hit" will skip it.
I don't know of baked in way of doing this. You can however set the "When hit" options of a breakpoint to run a macro. It shouldn't be hard to write a macro that gets the current line, and then sets the next debugger line. You'll probably want to look at the Debugger.SetNextStatement method.
A macro like this should do it:
Public Sub SkipNextLine()
ActiveDocument().Selection.LineDown()
DTE.ExecuteCommand("Debug.SetNextStatement")
End Sub
Yes, you can do this directly using a tracepoint.
Find the address of the return statement or final closing curly brace 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.
See also https://stackoverflow.com/a/14695736/301729
There's no way I know of to do this with a breakpoint but you can use compiler directives to skip code
#if (DEBUG)
//this code is skipped in debug mode
#endif
Try:
#if DEBUG
Response.Redirect("LoginFail.aspx");
#endif
Make sure you have the DEBUG constant checked in your build properties.
Agree with the use of compiler directives or any other requiring to add logic in code. However, also understand editing the debugged code is not always an option (e.g. not owning the code might imply not having all resources needed to build it).
If that's your case, I'm afraid that writing your own macro or waiting for VS to have one built-in equivalent are your only options.
I'm trying to simplify my debugging tasks and I had an idea which could increase my debugging speed.
Suppose I have a value, say 2.8651 that appear in the code at a moment I do not know.
I'm wondering if it was possible to create a super breakpoint which would stop at the first time one of the variable takes this value.
I recall that I do not know which variable takes the value.
I could know it by spending some time on the debugger but I'm lazy.
I'm not really familiar with VBA for VS. I guess, a solution would be to create a macro which would loop along local variable at each line of the code execution. It'd stop when the condition localVariable == 2.8651 is verified.
Thank you for your answers!
There's no such thing as a super breakpoint for a block of code. There are two options to achieve what you want:
Place a conditional breakpoint on each line with a variable assignment. Right-click the breakpoint and click Condition... to specify when it should break.
Place a single conditional breakpoint in the code block and check all the required variables in the condition.
As you suggested, you can place a single breakpoint with a macro, by right-clicking the breakpoint and select When Hit.... However, I highly doubt that it's possible to control the breakpoint from the macro, so this wouldn't work.