Visual Studio Code 0.10.10 released today with many new features including indentation-based code folding and UI support for configuring “function” breakpoints. In this blog post, I’ll show you a few new features what we have planned for the 0.5.0 release of the PowerShell extension for Visual Studio Code, which should be available towards the end of March. The two features I’ll show in this blog post are support for conditional breakpoints and function breakpoints in the VSCode debugger.
Conditional Line Breakpoints
Conditional line breakpoints will break on a line of script only when the user supplied condition evaluates to true. The following animated gif shows how to add a conditional breakpoints.
You can also add a condition to an existing line breakpoint by right-clicking on the breakpoint and selecting “Edit Breakpoint” e.g.:
Note that if you supply an invalid expression, it is currently a bit tricky to find out that the expression is invalid. If you find that your conditional breakpoint is not firing, I suggest you put a normal breakpoint before or after the conditional breakpoint and run your code. This should allow you to see what is wrong with the conditional breakpoint. Note the “dimmed” out breakpoint glyph below on line 7 and the tooltip describing what’s wrong with the condition e.g.:
With conditional breakpoint expressions, be sure to use “PowerShell” operators like -eq, -ne, -gt, -ge, -lt and -le.
That’s pretty neat but … we can do more.
Conditional breakpoints use the PowerShell breakpoint mechanism which allows you to run a user-supplied scriptblock when a breakpoint is encountered. This is what the Action parameter is for on the Set-PSBreakpoint command. The PowerShell extension uses this functionality behind the scenes to support VSCode conditional breakpoints. And the good news is that you have access to the Set-PSBreakpoint Action functionality as well.
When you type a basic expression such as “$i –eq 25”, that is converted to “if ($i –eq 25) { break }” and supplied to the Action parameter when the breakpoint is set. Most folks can provide a simple boolean expression as the condition upon which to break. However, advanced users can provide a expression that contains either a “continue” or a “break” statement and the expression will be passed “as-is” to the Action parameter. This allows you to create “tracepoints”. That is, a breakpoint that when triggered, will execute its “action” scriptblock and then automatically resume execution of the script – as if it had never stopped.
Tracepoints are handy when you want to sprinkle in a little “printf-style” debugging to output state information to the console without breaking into the debugger. And without having to modify the script. Maybe the script is signed and you don’t want to bother with resigning it (or stripping out the signature). Here’s an example that creates a tracepoint to output information about the state of the script as it runs.
Note that the script never appears to stop at the tracepoint. The script in fact, runs to completion after the Start button is pressed. Yet the tracepoint information has been written out to the Debug Console.
Function Breakpoints
Even though Visual Studio Code refers to this feature as “function breakpoints”, PowerShellers know this feature as “command breakpoints”. That is, you can set a breakpoint not just on a function in PowerShell but also on an alias, built-in command or application.
The use of function breakpoints is very straightforward as the next animated gif demonstrates:
Note that when the debugger stops on a “function breakpoint” there is no breakpoint glyph in the left gutter of the editor window like you would see for a line breakpoint. However, you can look in the call stack viewlet and it will indicate if the debugger is stopped on a function breakpoint with “PAUSED ON FUNCTION BREAKOINT”.
There you have it. A few minor debugging enhancements that can come in very handy. Remember, these features are in the v0.5.0 version of the PowerShell extension due out towards the end of March.
Keith Hill's Blog 