Task.json shouldn't need to be manually created to build .NET projects before debugging

[gregg-miskelly]

For .NET debugging, we currently need to have the user manually create a tasks.json in order to support build. We would like to find some solution to avoid the user needing to do this manually.

A few options:

1. Support simple shell commands directly inside of launch.json. So if all the user wants to do is execute a command with a default error syntax they don't need this extra file. Example:
   "preLaunchCommand": "dotnet compile"
   Which would execute 'dotnet compile' in the workspace directory.
   -or-
2. Support auto-generating a tasks.json when creating launch.json. This way we can give them a good default value of it and the user doesn't need to manually enter it.
   -or-
3. Support defining tasks in an extension's package.json. So the user only needs to create a launch.json if they want to do something weird.

[isidorn]

FYI @weinand @dbaeumer

[isidorn]

@gregg-miskelly after discussing with @dbaeumer we think it is best that we help the user generate tasks.json file. We can not move the task running logic inside the launch.json since then we would have to replicate all the tasks logic into debug.

Is the task that you want to run a preLaunchTask, or would the user want to run it independent of debug?

[gregg-miskelly]

Ideally, it would be nice if people could run it some other way too. But running it as a preLaunchTask is the biggest thing that we care about.

[isidorn]

After discussing with @dbaeumer we should introduce a way for an extension to contribute an 'initial' tasks.json. This should all live in the task framework, however this is not a small effort so moving it to the backlog and assigning to Dirk.

[rkeithhill]

After discussing with @dbaeumer we should introduce a way for an extension to contribute an 'initial' tasks.json .

Yes, please! With the PowerShell extension we want to provide a default task to run Pester tests. It would be great if an extension could provide the initial tasks.json file you get with Tasks: Configure Task Runner. We would also like to provide a problemMatcher that could be referenced from the Pester (test) task. The problemMatcher is somewhat lengthy and it would be nice to reference it like so:

{
    "version": "0.1.0",

    // Start PowerShell
    "command": "${env.windir}\\sysnative\\windowspowershell\\v1.0\\PowerShell.exe",

    // The command is a shell script
    "isShellCommand": true,

    // Show the output window always
    "showOutput": "always",

    // Allow Pester to invoke scripts and run Pester
    "args": [
        "-NoProfile",
        "Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process;",
        "Write-Host 'Invoking Pester...'; Invoke-Pester;",
        "Invoke-Command { Write-Host \"Completed all tasks in task runner: $($args[0])\" } -args"
        ],

    // Associate with test task runner
    "tasks": [
        {
            "taskName": "Pester",
            "isTestCommand": true,
            "problemMatcher": "$pester"
         }
    }
}

Seems like the package.json needs a contributes.Tasks where extension authors can contribute both problemWatchers and task initial configurations.

[egamma]

Moved the comment from @rkeithhill to #966.

[egamma]

After investigating into this issue we came up with the following proposal:

• Handle the situation more gracefully when a preLaunchTask cannot be found. This is tracked in Offer the user to configure a task when the 'preLaunchTask' isn't found #3081
• The .net extension should avoid this situation all together by creating a task.json for the user when one doesn't exist yet. This can be done when the extension is activated.

Rejected proposals:

• Support to launch a shell command as a preLaunchTask. To make this properly requires to support all the configuration options (e.g. platform specific commands) that is already provided by the task.json. It doesn't make sense to duplicate this inside the launch.json.
• Generate the task.json by the generator yo or aspnet - the generators do not want to generate tool specific files.

Closing this issue.