Debugging without an open folder

[shashankt1989]

Why is folder required to have debugging enabled?
Case in point - trying out single file ps scripts. Am I missing something?

[isidorn]

I see that your scenario would not require the workspace, however our vscode frontend has to support multiple languages to debug and for most having a workspace is required. Also debugging requires a launch.json file, and when there is no workspace there needs to be a shared launch.json which is a bit cumbersome.

Due to the above this is by design.

[shashankt1989]

So keep it as an open issue in case someone wants to code up a solution? Or is it something that we don't want to have at all because it would make the product worse?

[isidorn]

Let's keep it open for now then

[mateuszlewko]

Yes this would be a useful feature. Debuging just a single file. Please add this.

[davehope]

I'd like to explain a possible use case for this.

I use vscode to write PowerShell scripts, these are usually single-files. I'd like to be able to open a Powershell file, set some break points and debug the script like I can with the PowerShell ISE

[daviwil]

I'm starting to see a real need for this in the PowerShell extension but I'll bet that it'd also be helpful for other languages with a more dynamic/interactive development workflow (Python, F#, etc). Here's a thought:

1. The user opens VS Code and starts typing in a file then saves it with a .ps1 extension.
2. The user sets a breakpoint and presses F5
3. Because there isn't a folder currently open, VS Code assumes the user wants to launch the debug adapter for the extension that provides a debugger contribution for the current file type (in this case the PowerShell extension). It generates a launch.json in a temporary directory using the extension's default configuration and then launches the debug adapter with that.

It may be necessary to also have a different type of default, single-file configuration or maybe some way to generate one.

I realize there's some work required to enable this, but does this set of steps sound reasonable?

[isidorn]

@daviwil we actually had this feature 1 year ago but removed it because it was causing issues and did not provide any key benefits. I understand that the powershell users would definetly benefit from this now.
@weinand and @kieferrm can decide how high is this on our priority list

[daviwil]

Yeah, this is one of the core expectations of PowerShell users since it's a primary development workflow in the PowerShell ISE editor. I would love to work with you guys to find out a good way to enable this without disrupting the existing folder-based debugger configuration.

[TheKnightCoder]

I would also like this feature. Opening a single file with vs code feels kind of useless. Is it bad if vs code automatically opened the parent folder when someone opens a file with vs code.

[isidorn]

Ok let's do this, moving to January for exploration.
Was thinking a bit about this, imho we have two options:

1. Have a shared "launch.json" in a user folder which is used for all no-folder workspaces

• same experience as setting up regular debugging, all improvment which we do for launch.json will also benefit no folder debugging
• lets user customize to fine grained details for each no folder debug session
• variable substition will not work nicely, since things like ${workspaceRoot} are not availalbe in no folder debugging - this can be very confusing to the user
• might be overly complex in order to just run a simple file (e.g. powershell script)

2. No "launch.json" - implicitly always send the path to the currently opened file to the adapter

A user who gets used to this scenario might be shocked that once he opens a workspace he needs to setup a complex launch.json. This option obviously has the pro of being simple to setup but opens the following questions:

How to choose the correct adapter for a particular file, e.g a hello.ps1 script?

Currently adapter are not contributing in any way the extensions of the files they are interested in except via the breakpoints contribution. Using that contribution for this use case feels a bit hacky. Also what would we do if there are two adapter that contribute the same extension, we can be pragmatic and just take the first

Do we always launch or give a user to choose between launch / attach?

We could do this choice via quick pick but it is painful that the user always has to choose launch every time he wants to simply run his script. Recently we were talking to a team that have a use case of always attaching, so we should also support this imho.

Two options of quick pick not annoying the user:

• users first choice is remembered for the rest of the vscode session
• introduce a setting "debug.noWorkspaceRequest" which could by deafault be launch, but could also have attach and pick. Where pick would always ask the user.

Does the adapter require some arguments in the "attach" case?

Can the adapter just always pick the default port or do we need to do the pick process action?

UI state in no folder workspace

All ui state is preserved until vscode is closed. Which means on vscode restart all breakpoints will be lost. IMHO this is fine for the no folder debug scenario as this is our general no folder experience. If you want persistent state open a folder.

[weinand]

I don't like option 1 because managing a shared launch.json somewhere on disk sounds complex and it has the problems already identified by @isidorn.

For option 2 I propose a solution that aligns nicely with the theme to open up debugger functionality for extensibility. The basic idea is to optionally route the "debug" or "run" requests to a debugger extension which can modify a launch config in any way needed. In the "Debugging without an open folder" context the extension would have to create a launch config on the fly because none exists in the no-folder mode.

Details:

• for the debuggers contribution point we introduce a new optional sub-configuration point languages. Here those languages can be listed for which the debug extension could be considered the "default debugger". VS Code makes use of this information only in cases where a debugger must be found automatically for a given file type.

• for the debuggers contribution point we introduce a sub-configuration point startSessionCommand that takes a command ID. If specified, VS Code will call this command for the "debug" or "run" actions targeted for this extension. If a launch configuration was selected, it is passed as an argument to the command (and the extension can massage the launch config as desired). If "debug" or "run" is executed without an existing launch config, an empty launch config is passed to the "startSessionCommand" and the extension is expected to "fill in" missing attributes based on the file currently open in the editor.

[daviwil]

This looks great! I'll give it a try today. Judging from the code changes, it looks like this will also call my startSessionCommand when there is an open folder/workspace, is that correct? If so, that is excellent. This will let me give a much more streamlined debugging experience for PowerShell users both in the no-folder and workspace folder cases.

[daviwil]

Ahhh, finally just read Andre's design proposal above. I suppose this means the user will still be prompted to create a launch.json config on first launch in an open workspace. That seems ideal because it will allow the user to save debugger config parameters in their project's launch.json while still allowing the extension to augment their config before launching the debugger. This is really nice!

[isidorn]

it looks like this will also call my startSessionCommand when there is an open folder/workspace, is that correct?

Yes.

I suppose this means the user will still be prompted to create a launch.json config on first launch in an open workspace

No.
He will be prompted to create a launch.json if he clicks on the configure button or if he is trying to launch a file for which none of the debuggers are interested in.
Get the latest insiders tomorrow try it out and let us know if something does not make sense ;)

[daviwil]

That might be even better! I'll hold any further questions until I try it tomorrow :)

[weinand]

@daviwil I've updated the code in https://github.com/Microsoft/vscode-node-debug/blob/master/src/node/extension.ts#L256 to cover all cases.

[daviwil]

This is helpful, thanks! And thanks so much for getting this feature implemented, it's going to have a huge impact for the PowerShell extension.

[daviwil]

Just tried this out, it's fantastic! It works exactly like I hoped it would both with and without a folder loaded.

One problem though: after I execute the vscode.startDebug command, the debugger client starts up and sends the initialize request to my debug adapter but somehow my initialize response is never received even though I can see from my debug adapter's logs that I've sent it.

This even happens when I take my startSessionCommand registration back out and let VS Code handle starting the debug adapter. When I try my debug adapter with VS Code Stable everything works correctly. Could something in the debug adapter client's protocol have changed recently to cause messages to not be received?

[daviwil]

I should mention that to debug the issue I've set breakpoints in vs/workbench/parts/debug/electron-browser/rawDebugSession.ts in the initialize() and readCapabilities() methods. In the latest Insider build I can see initialize() get called but I never see readCapabilities() receive the response object until I wait a while and then stop the debugger. At that point it receives null.

[daviwil]

Just thought to check this with the latest official release of the PowerShell extension, version 0.8.0 which came out in mid-December. When starting the debug adapter it hangs on startup in the same way that I described above. Something definitely must have changed in how the debug adapter client communicates with debug adapters, but I'm not quite sure how.

If you want to give this a try, install the PowerShell extension and open the following folder (adjust the path appropriately for OS X if needed):

c:\Users\<your username>\.vscode\extensions\ms-vscode.PowerShell-0.8.0\examples\

Open the DebugTest.ps1 file in that folder and hit F5, you'll see that the debug adapter never fully starts up (no orange status bar).

[weinand]

@isidorn David's problem sounds like a regression to me. Can you look into this?

[isidorn]

Just verified that VScode is sending exactly the same requests as before.
What we introduced recently is a handshake node module between vscode and adapters but this should not effect powershell as your adapter is not sending the 'handshake' request.

I am currently git bisecting to see what commit caused the issue
In order to spot issues like this in the future sooner it would be cool if you guys self hosted on vscode insiders :)

[isidorn]

Here's the commit that breaks it - praise git bisect 🙏
140f1ec

Here's the commit that fixes the issue fb838d2

[weinand]

@isidorn but your commit does not explain what went wrong with the Map code. I'm using the identical Map code in node-debug and have no issues...

[daviwil]

Sorry about that, I'll use Insiders from now on. I had been using it in the past but somehow switched back over to stable.

Just pulled down the latest code after your change, that fixed it! Everything works perfectly now. Thanks a lot Isidor!

[isidorn]

After closer inspection with @weinand we figured out that the exact issue is that powershell is sending back strings instead of numbers for response.request_seq, so instead of 1 we are getting "1".
@daviwil can you look into fixing this issue on your side so we go back to our proper usage of es5 maps on our side.

[daviwil]

Hah! Wow, wouldn't have expected that. Yep, I'll make the change.

[daviwil]

I can confirm that changing request_seq to int in my message serializer fixed the issue in the Insider's build.

[isidorn]

Awesome - we'll go back to using a map