Skip to content

Hitting a breakpoint in the console while not debugging should activate the VS Code debugger #619

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
daviwil opened this issue Mar 24, 2017 · 5 comments
Labels
Issue-Enhancement A feature request (enhancement).
Milestone

Comments

@daviwil
Copy link
Contributor

daviwil commented Mar 24, 2017

Desired behavior:

  1. Open a .ps1 file and set breakpoints using Set-PSBreakpoint -Script <script> -Line <##>
  2. Run the script from the console by invoking with its script name
  3. PowerShell hits the breakpoint, activates VS Code's debugger, then shows the breakpoint hit at that line

This should also work for command and variable breakpoints.

@daviwil daviwil added the Issue-Enhancement A feature request (enhancement). label Mar 24, 2017
@daviwil daviwil modified the milestones: 0.12.0, Next Patch Update Mar 24, 2017
@daviwil daviwil modified the milestones: Next Patch Update, Next Feature Update Apr 6, 2017
@daviwil daviwil modified the milestones: April 2017, May 2017 May 8, 2017
@andrewducker
Copy link

Will this also work with breakpoints set from the editor?

@daviwil
Copy link
Contributor Author

daviwil commented May 11, 2017

That one is tricky because VS Code's debugger model doesn't give me information about breakpoints until the user starts the debugger. I've asked them about this already but we haven't come to a viable solution yet. It's the last step in making a 100% compatible debugging experience between VS Code and the ISE, so I definitely want to get it working!

@daviwil daviwil modified the milestones: May 2017, 1.1.0 May 15, 2017
daviwil added a commit to daviwil/PowerShellEditorServices that referenced this issue May 17, 2017
This change is part of the fix for PowerShell/vscode-powershell#619
which states that hitting a breakpoint in the integrated console does
not activate the debugger in VS Code.  The fix is to check whether a
debugger client is connected when a breakpoint is hit, and if not, send
a notification through the language server to have the editor connect
its debugger client.
daviwil added a commit to daviwil/vscode-powershell that referenced this issue May 17, 2017
This change adds new behavior which causes VS Code's debugger UI to be
activated when a breakpoint is hit in the Integrated Console while not
currently in debug mode.  This allows the user to set breakpoints and
run scripts from the console while still leveraging VS Code's rich
debugging UI.

Resolves PowerShell#619.
daviwil added a commit to PowerShell/PowerShellEditorServices that referenced this issue May 17, 2017
This change is part of the fix for PowerShell/vscode-powershell#619
which states that hitting a breakpoint in the integrated console does
not activate the debugger in VS Code.  The fix is to check whether a
debugger client is connected when a breakpoint is hit, and if not, send
a notification through the language server to have the editor connect
its debugger client.
daviwil added a commit that referenced this issue May 17, 2017
This change adds new behavior which causes VS Code's debugger UI to be
activated when a breakpoint is hit in the Integrated Console while not
currently in debug mode.  This allows the user to set breakpoints and
run scripts from the console while still leveraging VS Code's rich
debugging UI.

Resolves #619.
@beatcracker
Copy link

It doesn't work for me (or I'm failing to understand how it's supposed to work).

Steps to Reproduce:

  1. Create new module: Answer.psm1
  2. Add function to module:
function Get-Answer {
   42
}
  1. Open module in VS Code
  2. Set breakpoint by pressing F9 on 42
  3. Import module via PowerShell Integrated Console:
Import-Module -Path .\Answer.psm1
  1. Execute Get-Answer function from PowerShell Integrated Console:
Get-Answer
  1. Notice, that breakpoint doesn't trigger.

I've also tried sourcing *.ps1 file with function, but it doesn't trigger the breakpoint either. I can trigger breakpoint by running script file with F5 and then executing function from console, but I can't do this for module. It throws Cannot run a document in the middle of a pipeline error.

Details

  • VSCode Version: Code 1.15.1 (41abd21afdf7424c89319ee7cb0445cc6f376959, 2017-08-16T18:07:25.676Z)
  • OS Version: Windows_NT x64 6.3.9600
  • Extensions:
Extension Author (truncated) Version
PowerShell ms- 1.4.1

@changbowen
Copy link

changbowen commented Aug 6, 2019

I'm using the below combination and it seems that the above feature (launching from Integrated Console expecting breakpoint to be hit) only works if you manually start then stop the debugger (by hitting F5) for at least once. Is it by design or am I missing some options?
Also seems that when a breakpoint is removed, it still triggers for another time when launching script from Integrated Console. This doesn't happen by hitting F5.
And sometimes breakpoints stop triggering again and needs an F5...
The feature is handy when debugging with pipeline inputs. And ISE handles it well when launching from its Integrated Console. But ISE... ugh...

Version: 1.36.1
Commit: 2213894ea0415ee8c85c5eea0d0ff81ecc191529
Date: 2019-07-08T22:59:35.033Z
Electron: 4.2.5
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

@ghost ghost added the Needs: Maintainer Attention Maintainer attention needed! label Aug 6, 2019
@SydneyhSmith
Copy link
Collaborator

@changbowen you are not missing anything--that is a limitation of this debugging experience today where you must hit F5 at least once

@SydneyhSmith SydneyhSmith removed the Needs: Maintainer Attention Maintainer attention needed! label Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Enhancement A feature request (enhancement).
Projects
None yet
Development

No branches or pull requests

5 participants