Debugger not started when breakpoint is set in the editor

[DarkLite1]

System Details

• Operating system name and version: Windows Server 2012 64 bit
• VS Code version: 1.15.0-insider
• PowerShell extension version: 1.4.1
• Output from $PSVersionTable:
  Name Value

---

PSVersion 5.1.14409.
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0,
BuildVersion 10.0.14409
CLRVersion 4.0.30319.
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Copy / paste the below commands into the PowerShell Integrated Terminal, and paste the output here

code -v
code : The term 'code' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the pa
th is correct and try again.
At line:1 char:1
+ code -v
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (code:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

PS S:\Prod> $pseditor.EditorServicesVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
1      4      1      0

PS S:\Prod> code --list-extensions --show-versions
code : The term 'code' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the pa
th is correct and try again.
At line:1 char:1
+ code --list-extensions --show-versions
+ ~~~~
    + CategoryInfo          : ObjectNotFound: (code:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Issue Description

The debugger is not started on a fresh start of vs code. Steps to reproduce the issue.

Step 1

Create file Testie.ps1 with content:

[CmdLetBinding()]
Param (
    [Parameter(Mandatory)]
    [String]$ProcessName
)
 
<# TESTs
    $TestParams = @{
        ProcessName  = 'Code'
        Verbose      = $true
    }
    &'S:\Test\Brecht\Testie3.ps1' @TestParams
#>

Write-Verbose "Script started"
Get-Process | where Name -Like "$ProcessName*"
Write-Verbose "Debugging done"

Step 2
Set a breakpoint at line 16 by clicking F9.

Step 3
Select the code in the comments and click F8.
(The purpose of doing it this way is to have the parameter validation done)

Observe that the script is completely executed without stopping at line 16. The current workaround is to run the whole script by clicking F5 and then doing step 3 again.

[rkeithhill]

Running select script using the F8 key doesn't start the debugger which is why your breakpoint is not hit.

However, if you have a folder open i.e. are in workspace mode, then go to the Debug view and select "PowerShell: Interactive Session" from the drop down and then press F5 to attach the debugger to your live running PowerShell Integrated Console. If your Debug config drop down is empty, press the Gear icon and add the PowerShell: Interactive Session debug configuration. Now when you select that text and press F8 your breakpoint will be hit.

[DarkLite1]

Thx @rkeithhill , this is indeed a valid workaround. However, I'd still consider this as a bug because in the standard PowerShell ISE this workflow does not require extra steps.

It just seems logical that when a user adds a breakpoint in the GUI, the debugger always stops at that point, regardless of where the script is invoked from.

[rkeithhill]

I would be a little careful comparing ISE to VSCode at least when it comes to determining what is a bug. ISE was built for PowerShell editing. VSCode was built as a code editor that initially at least, targeted web development languages (HTML, JS, CSS). But through a very nice extension mechanism, allowed many other languages to "plug into" VSCode.

In particular, the debug protocol is owned by VSCode. That's not to say that the VSCode folks aren't listening and wouldn't make some tweaks for PowerShell but they also have to balance the needs of all the other language debuggers. IIRC the debug protocol currently only allows "initiation" of debugging when the user starts debugging from VSCode.

[MartinSGill]

I'd consider this a bug as well, as @joeyaiello has said VSCode has feature parity with ISE.

The feature is mostly there, but there's an extra couple of step required that won't be obvious to people coming from ISE:

• You need to create a launch.json for debug configurations (luckily there is an excellent default)
• You need to select "Powershell Interactive Session"
• You need to start the debugger.

What adds to the confusion is that the "Powershell Integrated Console" starts with a powershell file, but doesn't behave as expected until you actually start the debugger running. The good news here is that it at least remembers what you've already done.

As an extra note. the debug keyboard shortcuts do not work if the console has focus (i.e. if you run a script from the console), which is rather annoying. Knowing the debug commands helps, but I suspect most people don't.

[rkeithhill]

"Powershell Integrated Console" starts with a powershell file, but doesn't behave as expected until you actually start the debugger running

What do you mean exactly? Are you referring to missing features like history, multiline editing or something else?

the debug shortcuts do not work if the console has focus

I submitted this and it has been fixed. I've verified the fix in the Insiders build. microsoft/vscode#38023

[SeeminglyScience]

Maybe I'm going crazy but I could have sworn a few builds ago if you hit a breakpoint in the console it would trigger debug session. Do we no longer have the ability to start a debug session on the fly? If it's still possible to trigger a debug session in VSCode on debugger stop events, and if the new(ish) break point notifications in VSCode work how I think, then I would think full parity would be achievable.

[MartinSGill]

I'll try a different way of explaining what I mean. I'm using VSCode 1.19.0, which I believe is the current latest release.

In ISE:

1. Start Editor with file (e.g. PS> ise mystuff.psm1)
2. Set a breakpoint inside a function.
3. In Console "Import-Module mystuff.psm1"
4. In Console call imported function
5. Break-point hit, execution stops in debugger

The steps as above in VSCode:

1. Start Editor with file (e.g. PS> code mystuff.psm1) (no .vscode folder exists)
2. Set a breakpoint inside a function.
3. In Console "Import-Module mystuff.psm1"
4. In Console call imported function
5. Break-Point never hit.

I would consider this to be the "intuitive" behaviour, especially for someone coming from ISE.

Steps in VS Code to actually get it working. This is basically the I did when I was trying to figure out if I could get it working like ISE at all. Now I know how it works I can skip a few steps, but I believe this to be what someone coming from ISE is likely to also try.

Addition steps required are in bold.

1. Start Editor with file. (e.g. PS> code mystuff.psm1) (no .vscode folder)
2. Set a breakpoint inside a function.
3. Select "Debug" sidebar
4. Click on "Configure or Fix Launch.json"
5. Error: "Please first open a folder in order to do advanced debug configuration."
6. Add folder my file is in.
7. VS Code Restarts, repeat steps 1 to 5
8. Default launch.json is created
9. Select "Powershell Interactive Session" from Debug Configurations
10. Start Debug
11. In Console "Import-Module mystuff.psm1"
12. In Console call imported function
13. Breakpoint Hit

While I am sure there are limitations in what is possible in VS Code, given it's a generic editor and not specifically a powershell editor, it surely must be possible to reduce the number of steps.

Even if you remember to open a folder and not a file directly, it's still 10 steps, as opposed to the 5 in ISE before you can hit a breakpoint when using the console.

If there's an easier way to do this, or a setting that I'm missing somehow, please let me know.

[hanpq]

I agree with @MartinSGill, this is much more expected behavior when coming from ISE and quite frankly I tried a couple of months ago to figure out how to achieve this but simply gave up (reasoning that everything will simply not be the same in VSCode as in ISE) and have simply temporarely added the function call to the end of the script (containing the function definition) to be able to debug the code with F5.

Thanks to @MartinSGill I've now tested 13-step procedure to get this working and it indeed works which is good but not very user friendly. Additionally, you always need to be aware of the current mode of debugging and change mode between “Powershell Integrated Debugging” and “Powershell: Launch Current File” quite frequently. On the contrary in ISE this was completely transparent any you could debug with "both methods" interchangeably.

[hanpq]

I've tried to read up on launch configurations but I've not figured the following out; would it be possible to "chain" two debugging configurations into one launch-configuration?

Lets say I have a script containing a function definition. I hit F5 and the launch configuration launches the "Powershell Launch Current File" to re-define the function in the runspace and directly after starts and leaves the debugger running according to the "Powershell Interactive Session"-launch configuration which would allow me to call the function from the integrated terminal only running one launch configuration instead of two different launch configurations after one another?

Does that make sense? :)

(This would be a temporary solution until this enhancement gets implemented (if launch configurations support this "feature" that is)