You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#10338 removed the ScriptDebugger.SetBreakpoints() API, allowing .NET code to set breakpoints.
Although previous PowerShells didn't have a convenient way to create a breakpoint object, removing this API means there's no way to avoid reflection when setting a breakpoint in a PowerShell module targeting anything prior to PS 7.
This is an issue for PowerShellEditorServices, where good debugging APIs are already scarce. A break like this will crash PSES unexpectedly (since PSStandard doesn't pick it up) and the only fix is to use reflection to find the right call at runtime (nullifying the reason to use PSStandard).
Since we're putting this back, we should probably have it call the other APIs for setting breakpoints since they are connected through all of the debugger layers (local debugger, remote debugger, etc.).
No need to be sorry. We ought to have tooling to check this.
Since we're putting this back, we should probably have it call the other APIs for setting breakpoints since they are connected through all of the debugger layers (local debugger, remote debugger, etc.).
I agree, but those APIs don't take a Breakpoint object. If the caller is expecting their breakpoint to be the one registered in the debugger, with referential equality intact, that may mean we need to use a different call path.
Activity
rjmholt commentedon Oct 16, 2019
/cc TylerLeonhardt Steve Lee (@SteveL-MSFT) James Truher (@JamesWTruher) Aditya Patwardhan (@adityapatwardhan) Kirk Munro (@KirkMunro) Paul Higinbotham (@PaulHigin)
SteveL-MSFT commentedon Oct 16, 2019
Rob Holt (@rjmholt) can you submit a PR to bring back that public API?
KirkMunro commentedon Oct 16, 2019
Sorry about that Rob Holt (@rjmholt).
For reference if you don't have them already, here is the related discussion and the commit where that API was removed.
Since we're putting this back, we should probably have it call the other APIs for setting breakpoints since they are connected through all of the debugger layers (local debugger, remote debugger, etc.).
rjmholt commentedon Oct 16, 2019
No need to be sorry. We ought to have tooling to check this.
I agree, but those APIs don't take a Breakpoint object. If the caller is expecting their breakpoint to be the one registered in the debugger, with referential equality intact, that may mean we need to use a different call path.
iSazonov commentedon Nov 16, 2019
Fixed in #10808