Open xinyanmsft opened 7 years ago
This needs work on both end the debugger and the task framework.
Has there been any movement on this one? something I just ran into and would make life much easier if it were available.
This would help me a ton too. I want to be able to select an option in launch.json, and pass that option to the subsequent pre and post launch tasks. The way I have it set up now means that I have to choose the option 3 separate times
I'm also running into issues with this. I have a launch configuration that prompts for the IP address. It then has a preLaunchTask to do some preparation on the device but that task then has to prompt for the same IP address again.
Related to this:
How about having the cwd
from the launch configuration automatically applied to its preLaunchTask
when the task itself does not specify otherwise?
Is this possible somehow?
cwd
is nothing that VS Code knows about. A debug extension owns the schema for its launch attributes and only some define cwd
(and VS Code cannot make any assumptions about the semantics of cwd
anyway; it can only guess...).
cwd
is nothing that VS Code knows about. A debug extension owns the schema for its launch attributes and only some definecwd
(and VS Code cannot make any assumptions about the semantics ofcwd
anyway; it can only guess...).
Thanks for clarifying.
I feel like I fell into the same trap as many do - difficulty with discerning where VSCode's responsibility ends and extensions' begins.
Currently looking at the same issue. Launch configuration that prompts for the target's IP address. I'd like to pass that IP address to a preLaunchTask
(running prep on the target). Right now I have to type it in twice.
Any word on this? This would still be incredibly helpful
+1
+1 It would help with multiple configuration. e.g. building a cpp project, often requires to build with the configuration you want to launch. Repeating the arguments can be cumbersome, and inefficient.
Have an idea how to implement this feature:
launch.json configurations: add field "preLaunchTaskInputs" of type {[taskInputName: string]: string}
.
User can specify values to be used for inputs inside of preLaunchTask. For example, if your preLaunchTask has ${input:SelectColor}
, you can add to your configuration:
"preLaunchTask": "Paint my car",
"preLaunchTaskInputs": {
"SelectColor": "Pink"
}
And task will have it's input value already and will not prompt user. If preLaunchTask does not have input with name of "SelectColor", then it is just ignored.
Also, prob would be cool to have something like ${defaultTasksInputValue:SelectColor}
which will search for task input with name "SelectColor" and use it's default value. If default value is not specified, or if task is not found - fail execution.
As well as ${defaultLaunchInputValue:SelectColor}
, if input belongs to launch.json
file.
Examples: launch json: https://pastebin.com/7Q0x4ZeP tasks json: https://pastebin.com/pv6a2tEi
+1 I need that feature too.
+1 for this feature. I think that ${input:foo}
defined in launch.json shall be expanded in tasks.json seamlessly.
Interestingly enough, if I define an input foo
in "inputs"
only in the launch.json and use ${input:foo}
in tasks.json, then the error message says that the input shall defined in launch.json OR tasks.json - which is in-fact what I did. :)
As others did, the temporary workaround that I am using is to define the input foo
in both launch.json and tasks.json, with the effect that the user is required to input such a twice.
Currently when invoking preLaunchTask, the only possible is the task name. It would be great if properties in the associated configuration can be passed to preLaunchTask.
Scenario: I am writing a pre-launch task to automate remote node.js debugging. The pre-launch task will launch the node.js process remotely and establish a SSH tunnel (port forwarding) back to local computer. And then debugger connects to that forwarded port to start debugging. The node.js debugger port is specified in launch.json file, and there is no good way for the pre-launch task to get the debugger port.
The problem can be solved if preLaunchTask can take parameters from the configuration. For example, tasks.json allow '$config.port' as args:
@isidorn @weinand