PowerShell / PowerShell/PowerShellEditorServices

Write event on configurationDone for attach requests

オープン
#2,245 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Issue-Enhancement Needs: Triage
主要言語
C#
スター
767
フォーク
266
平均マージ
3日 16時間
マージ済み PR(30日)
1

説明

Prerequisites
  • I have written a descriptive issue title.
  • I have searched all issues to ensure it has not already been requested.
Summary

On attach scenarios, it is not possible to wait for all the breakpoints set by the client to be set in the remote runspace. A client could have something like

$originalRunspaces = Get-Runspace

Read-Host -Prompt "Please attach to process $pid with runspace $([Runspce]::DefaultRunspace.Id)"

# Waits for VSCode to attach to runspace, an extra runspace will be created by
# Enter-PSHostProcess
while ($true) {
    $newRunspace = Get-Runspace | Where-Object { $_.Id -notin $runspaces.Id } | Select-Object -First 1
    if ($newRunspace) {
        break
    }
    Start-Sleep -Milliseconds 300
}

& .\script.ps1

But this only checks that PSES has attached to the named pipe. It won't wait for PSES to have called Debug-Runspace on the target runspace and more importantly any breakpoints inside script.ps1 to be set. It's also error prone if you cannot control when the attach actually happens as the additional runspace check could have occurred before the first Get-Runspace call.

What would be ideal is for a well known event to be created by PSES when configurationDone was received so that the client only had to do

# Attach to this runspace somehow

$e = Wait-Event -SourceIdentifier PSES.ConfigurationDone -Timeout 30
if ($e) {
    $e | Remove-Event
}
else {
    throw "Timed out waiting for attach event"
}
Proposed Design

My proposal requires some changes to PowerShell itself but I wanted to see if the general idea was acceptable before trying to propose the change there. The benefit of using an event is that no custom functions needed to be loaded, and subsequently checked by the code, and Wait-Event has a simple timeout operation.

Ultimately what needs to happen is for PowerShell to expose a __New-Event command, similar to the new __Set-PSBreakpoint commands, that is treated specially by the PSRemoting server. This would be able to do the following but without having to spin up a new pipeline.

$runspace = Get-Runspace -Id $runspaceId
$runspace.Events.GenerateEvent($SourceId, $Sender, $EventArgs, $EventData)

We cannot just have PSES run this script or call New-Event directly as the runspace pipeline is busy running Debug-Runspace. The only time it can run commands is if the caller ran Wait-Debugger which is not ideal as it will pause the execution and require the client to continue on manually.

An alternative that I haven't tried out yet is to delay Debug-Runspace until after configurationDone is sent. This would allow both the breakpoints and event to be manually emited as commands on the runspace specified without having to block the pipeline with Debug-Runspace. I am not sure if that will be possible though but it could be an option that doesn't require any changes to PowerShell itself.

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、PowerShell Editor Services の attach フローと、debug adapter protocol の configurationDone リクエストの処理を追跡し、次に issue で説明されている PowerShell remoting のイベント API を確認します。ブレークポイントの設定後に、attach クライアントが既知の PSES.ConfigurationDone イベントを待機できれば完了です。まず、これに PowerShell 自体の変更が必要なのか、それとも PSES のみの変更で済むのかを判断してください。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
csharp, powershell
領域
devtools
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。