Repository navigation
Startup script for temporary interactive console debug sessions #1168
Description
System Details
- Operating system name and version: Windows 10 x64 (Multiple builds)
- VS Code version: 1.19.2
- PowerShell extension version: 1.5.1
- Output from
$PSVersionTable:
Name Value
---- -----
PSVersion 5.1.15063.786
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.786
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
PS C:\> code -v
1.19.2
490ef761b76b3f3b3832eff7a588aac891e5fe80
x64
PS C:\> $pseditor.EditorServicesVersion
Major Minor Build Revision
----- ----- ----- --------
1 5 1 0
PS C:\> code --list-extensions --show-versions
ms-vscode.PowerShell@1.5.1
PS C:\> $PSVersionTable
Name Value
---- -----
PSVersion 5.1.15063.786
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.15063.786
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Issue Description
As it stands, debugging a module in VSCode is still a bit clunky. Debug configurations allow for generating a temporary integrated console for every debug session, but using this option requires manually importing the module every debug session.
There is also the option of running a script via the script attribute in a debug configuration entry, which could potentially be used to run environment setup (module import, etc.) - however, the integrated console closes once the script completes. It would be helpful if there was a way to specify a startup script for temporary consoles in a debug configuration, so module imports and whatnot could be done automatically.
Activity
hmmwhatsthisdo commentedon Jan 18, 2018
After speaking with
@seeminglyscienceon the PowerShell Slack team, it sounds like most of the work needed for this would be on the PSES side - however, I'm having trouble figuring out specifically what would need to be implemented on the PSES side vs. what would need to be implemented here.rkeithhill commentedon Jan 18, 2018
There is already a startup script
Microsoft.VSCode_profile.ps1. It just is a user thing instead of a workspace thing. Given the way the PSIC works now, any sort of "startup" only needs to be run once because the language session and all debug sessions share the same PowerShell instance. You can see this with$pidin the PSIC at various phases of its use. Unless you are using temp integrated consoles, which disappear before you get a chance to check your output. :-(That said, I do think it would be nice to have a workspace specific startup script or maybe even a
workspace profile. The downside to a startup script is that we'd need to make that a setting and then we'd need to pass the path to the startup script from the extension to PSES (not a big downside mind you). If we made it a profile, it would have a specific name and if it existed it would just get run with no need to specify any extension setting. Either way, at this time, the default behavior would be that it runs once, when PSES first starts.For a temp integrated console, perhaps a workspace profile could access variables to let you know which debug launch config is currently active. This is where I dither a bit. Is it easier to have a single workspace profile that could tell the diff between lang/debug sessions and know which debug config (name?) is active and then put all your logic in there to handle different debug scenarios. Or is it easy to have a property on the debug launch config where you specify a path to various startup scripts.
SeeminglyScience commentedon Jan 18, 2018
I believe he's talking mostly about temporary interactive debugging sessions which is where an init script would be the most helpful.
That was my thought. I can see that potentially being useful for all debug configuration types, but in particular temp interactive sessions. Assuming that's a reasonably easy property to add, I think that's the best way to go.
About workspace profiles, I really like the idea of them for preparing intellisense/loading editor commands from #190. I think mixing debugging into that, or having a separate profile for it might be confusing.
rkeithhill commentedon Jan 18, 2018
Well for the vast majority of folks that will not discover the temp int console setting, such a profile would mix with debugging. Maybe that setting should be a setting on the launch configuration instead - at least for configs like launch script, current file and current file w/args. We also really, really need to fix the behavior that the temp console closes immediately after the script finishes.
[-]Startup script for interactive integrated console debug sessions[/-][+]Startup script for temporary interactive integrated console debug sessions[/+][-]Startup script for temporary interactive integrated console debug sessions[/-][+]Startup script for temporary interactive console debug sessions[/+]hmmwhatsthisdo commentedon Jan 18, 2018
Keith Hill (@rkeithhill), Patrick Meinecke (@SeeminglyScience): I totally neglected to mention I was talking about the temporary interactive console - whoops! I'm editing the issue text now.
This is what I think would be the easiest from a usability perspective - that, or re-use the current
scriptattribute on debug configurations and add an attribute similar to PoSH's-NoExitswitch.mud5150 commentedon Mar 6, 2019
I would also love to see this happen. Using the
createTemporaryIntegratedConsolereduces the side effects from loading the module multiple times. I would love to also have some way to have it load the module into the temp console when I hit debug.JustinGrote commentedon Apr 22, 2020
Sydney Smith (@SydneyhSmith) this should probably be reclassified to an enhancement.
mdgrs-mei commentedon Nov 12, 2023
Now it seems that the temporary integrated console does not close after the
scriptfinishes which means it could be used as a startup script.I'm using ms-vscode.powershell@2023.8.0.
jul-m commentedon Sep 21, 2024
Indeed, the console does not close, but the debugger stops, so it is not possible to debug when the
scriptproperty is set. This is not due to thevscode-powershellplugin, but related toPowerShellEditorServices.I was able to find a workaround by modifying a line of code in
PowerShellEditorServices. I opened a discussion in their repository for interested people: PowerShell/PowerShellEditorServices#2180