launch.json: "${command:pickProcess}" prompts for a process to attach to *before* running pre-launch tasks

[mklement0]

As of VSCode v1.35.1, a launch configuration defined in launch.json that uses "${command:pickProcess}" as its "processId" value - in order to prompt for a process to attach to - does so before running any pre-launch tasks (preLaunchTask property).

• Is this by design?
• Is there a way to reverse this order?

The reason I want my prelaunch task to run first is twofold:

• generally, since my prelaunch task includes building, I want the launch to be aborted if building fails.

• specifically, my prelaunch task creates the process that I then want to attach to.

Taking a step back, my ideal solution would be to have the prelaunch task not only create the process to attach to, but to have the launch configuration automatically attach to it afterwards, but I haven't found a way to do that, given that:

• starting the debugger from the command line isn't supported yet - though support is being considered - see Suggestion: Start VSCode debugger from the command-line #10979

• there seems to be no way to populate a launch-configuration property from an arbitrary shell command (you can only call VSCode-internal commands via ${command:...}).

Note: I hit this limitation when trying to debug binary PowerShell modules via an external PowerShell console. I've since realized that the C# debugger automatically attaches to any external process created via a "request": "launch" launch configuration, so launching a PowerShell console that way (with a startup command that imports the binary module) is sufficient.

[RandomGHUser]

I too am having this exact same problem. I would expect my prelaunch task (which stops my remote process, builds and pushes my project to the remote box, then restarts the remote process) to finish executing before picking the process to attach to.

There are easy enough workarounds, but it should be able to work with a single launch configuration.

[weinand]

@isidorn what is the order of resolving variables and running the prelaunch task?

[isidorn]

We first resolve the varialbes and then run the preLaunchTask. Code pointer

[weinand]

this makes sense because the "preLaunchTask" attribute could contain a variable too.
So this works as designed.

[mklement0]

Understood re current design, but I think there is a usability issue here:

It doesn't make sense to pick a process first, if the pre-launch task can fail.

I understand that variable resolution coming first is what triggers the untimely prompting, but I wonder if an exception can be made in this case: defer any "${command:pickProcess}" actions until after the pre-launch tasks have run successfully.

If not all cases of untimely prompts can reliably be inferred (given that there can be arbitrary extension-supplied commands such as extension.pickNodeProcess), perhaps an opt-in property could solve the problem.