Skip to content

Breaking API removal in #10338 #10799

Closed
Closed

Description

@rjmholt

#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).

Activity

  1. added
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on Oct 16, 2019
  2. added
    Issue-BugIssue has been identified as a bug in the product
    and removed
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on Oct 16, 2019
  3. SteveL-MSFT commented on Oct 16, 2019

    @SteveL-MSFT
    Member

    Rob Holt (@rjmholt) can you submit a PR to bring back that public API?

  4. KirkMunro commented on Oct 16, 2019

    @KirkMunro
    Contributor

    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.).

  5. rjmholt commented on Oct 16, 2019

    @rjmholt
    CollaboratorAuthor

    Sorry about that Rob Holt (@rjmholt).

    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.

  6. iSazonov commented on Nov 16, 2019

    @iSazonov
    Collaborator

    Fixed in #10808

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions