René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Write event on configurationDone for attach requests","articleBody":"### Prerequisites\n\n- [x] I have written a descriptive issue title.\n- [x] I have searched all [issues](https://github.com/PowerShell/PowerShellEditorServices/issues?q=is%3Aissue) to ensure it has not already been requested.\n\n### Summary\n\nOn 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\n\n```powershell\n$originalRunspaces = Get-Runspace\n\nRead-Host -Prompt \"Please attach to process $pid with runspace $([Runspce]::DefaultRunspace.Id)\"\n\n# Waits for VSCode to attach to runspace, an extra runspace will be created by\n# Enter-PSHostProcess\nwhile ($true) {\n    $newRunspace = Get-Runspace | Where-Object { $_.Id -notin $runspaces.Id } | Select-Object -First 1\n    if ($newRunspace) {\n        break\n    }\n    Start-Sleep -Milliseconds 300\n}\n\n\u0026 .\\script.ps1\n```\n\nBut 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.\n\nWhat 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\n\n```powershell\n# Attach to this runspace somehow\n\n$e = Wait-Event -SourceIdentifier PSES.ConfigurationDone -Timeout 30\nif ($e) {\n    $e | Remove-Event\n}\nelse {\n    throw \"Timed out waiting for attach event\"\n}\n```\n\n### Proposed Design\n\nMy 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.\n\nUltimately 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.\n\n```\n$runspace = Get-Runspace -Id $runspaceId\n$runspace.Events.GenerateEvent($SourceId, $Sender, $EventArgs, $EventData)\n```\n\nWe 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.\n\nAn 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.","author":{"url":"https://github.com/jborean93","@type":"Person","name":"jborean93"},"datePublished":"2025-07-23T04:29:54.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/2245/PowerShellEditorServices/issues/2245"}