Should we check-in a default set of tasks to make it easier to work within vscode?

[ViktorHofer]

I just created this cross-plat tasks.json file which makes it possible to run the following basic commands on an opened project/solution file within vscode without using the integrated terminal (like in VS):

• dotnet restore
• dotnet build
• dotnet test
• dotnet pack

The tasks use the repo local dotnet.cmd/sh scripts so there's no dependency on a globally installed SDK. They work cross-plat on both Windows and Unix platforms. I wonder if we want to check that file in so that it becomes much easier to work on dotnet/runtime within vscode.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "presentation": {
        "reveal": "always",
        "panel": "shared",
        "focus": true
    },
    "tasks": [
        {
            "label": "dotnet restore",
            "detail": "Restore the currently opened .NET project.",
            "command": "${workspaceRoot}/dotnet.sh",
            "args": [
                "restore",
                "${file}"
            ],
            "windows": {
                "command": "${workspaceRoot}\\dotnet.cmd"
            },
            "type": "shell",
            "promptOnClose": true,
            "problemMatcher": "$msCompile"
        },
        {
            "label": "dotnet build",
            "detail": "Build the currently opened .NET project.",
            "command": "${workspaceRoot}/dotnet.sh",
            "args": [
                "build",
                "${file}"
            ],
            "windows": {
                "command": "${workspaceRoot}\\dotnet.cmd"
            },
            "type": "shell",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "promptOnClose": true,
            "problemMatcher": "$msCompile"
        },
        {
            "label": "dotnet test",
            "detail": "Test the currently opened .NET project.",
            "command": "${workspaceRoot}/dotnet.sh",
            "args": [
                "test",
                "${file}"
            ],
            "windows": {
                "command": "${workspaceRoot}\\dotnet.cmd"
            },
            "type": "shell",
            "group": {
                "kind": "test",
                "isDefault": true
            },
            "promptOnClose": true,
            "problemMatcher": "$msCompile"
        },
        {
            "label": "dotnet pack",
            "detail": "Pack the currently opened .NET project.",
            "command": "${workspaceRoot}/dotnet.sh",
            "args": [
                "pack",
                "${file}"
            ],
            "windows": {
                "command": "${workspaceRoot}\\dotnet.cmd"
            },
            "type": "shell",
            "promptOnClose": true,
            "problemMatcher": "$msCompile"
        }
    ]
}

cc @dotnet/runtime-infrastructure @danmoseley @ManickaP

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkoritzinsky]

I started working on building an extension for vscode for working with this repo. I think adding some of these tasks might be useful, but we should make sure to add support for non-libraries workflows as well.

[ViktorHofer]

I presume we don't need an extension for the workflows that src/libraries contributors care about: building, testing, debugging, packaging. Those basic workflows should work well with just a tasks.json and a launch.json.

Do you need an extension for the native side of the build?

[ManickaP]

Well, I never open repo root, so :shrug:

[lambdageek]

The fundamental problem that I have with VS Code launch and tasks JSON files is that if you check them into the repo, it is impossible (as far as I can tell) for users to make their own customizations without getting them destroyed every time they do a git checkout. if I want to add tasks that only make sense for my scenario, there doesn't seem to be a tasks.user.json that I can add. (also no tasks.json in subfolders. so if you add one in the repo root .vscode folder tailored to libraries contributors, it makes it harder, not easier, to work in other parts of the repo).

honestly the whole thing seems like not a good fit for collaborative work.

---

Maybe what we should do is add .vscode/ to .gitignore and then add a script that creates default launch.json and tasks.json by copying them out of some eng/vscode-templates/ folder

[jkoritzinsky]

I presume we don't need an extension for the workflows that src/libraries contributors care about: building, testing, debugging, packaging. Those basic workflows should work well with just a tasks.json and a launch.json.

Do you need an extension for the native side of the build?

There's some primitive prompting support for launching debugger processes that works for most scenarios. I've been able to set up a launch.json file that works for most of my scenarios with basic prompts, but it's limited in scope and doesn't cover all testing scenarios. Additionally, many of the test scenarios, in particular when I'm trying to test crossgen2 or NativeAOT against a runtime test, require me to have already run some commands (usually running the test once from the command line).

The fundamental problem that I have with VS Code launch and tasks JSON files is that if you check them into the repo, it is impossible (as far as I can tell) for users to make their own customizations without getting them destroyed every time they do a git checkout. if I want to add tasks that only make sense for my scenario, there doesn't seem to be a tasks.user.json that I can add. (also no tasks.json in subfolders. so if you add one in the repo root .vscode folder tailored to libraries contributors, it makes it harder, not easier, to work in other parts of the repo).

honestly the whole thing seems like not a good fit for collaborative work.

Maybe what we should do is add .vscode/ to .gitignore and then add a script that creates default launch.json and tasks.json by copying them out of some eng/vscode-templates/ folder

This is the other issue I had with sharing my local tasks/launch files. I think producing an extension that can help auto-populate these files with known-functioning defaults would be very helpful.

[ManickaP]

On the side note, I've been storing my launch and task settings in a workspace file that I keep outside of the repository to preserve it between repo cleans and pulls.

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure See info in area-owners.md if you want to be subscribed.

Issue Details

---

I just created this cross-plat tasks.json file which makes it possible to run the following basic commands on an opened project/solution file within vscode without using the integrated terminal (like in VS): - `dotnet restore` - `dotnet build` - `dotnet test` - `dotnet pack` The tasks use the repo local dotnet.cmd/sh scripts so there's no dependency on a globally installed SDK. They work cross-plat on both Windows and Unix platforms. I wonder if we want to check that file in so that it becomes much easier to work on dotnet/runtime within vscode. ```json { // See https://go.microsoft.com/fwlink/?LinkId=733558 // for the documentation about the tasks.json format "version": "2.0.0", "presentation": { "reveal": "always", "panel": "shared", "focus": true }, "tasks": [ { "label": "dotnet restore", "detail": "Restore the currently opened .NET project.", "command": "${workspaceRoot}/dotnet.sh", "args": [ "restore", "${file}" ], "windows": { "command": "${workspaceRoot}\\dotnet.cmd" }, "type": "shell", "promptOnClose": true, "problemMatcher": "$msCompile" }, { "label": "dotnet build", "detail": "Build the currently opened .NET project.", "command": "${workspaceRoot}/dotnet.sh", "args": [ "build", "${file}" ], "windows": { "command": "${workspaceRoot}\\dotnet.cmd" }, "type": "shell", "group": { "kind": "build", "isDefault": true }, "promptOnClose": true, "problemMatcher": "$msCompile" }, { "label": "dotnet test", "detail": "Test the currently opened .NET project.", "command": "${workspaceRoot}/dotnet.sh", "args": [ "test", "${file}" ], "windows": { "command": "${workspaceRoot}\\dotnet.cmd" }, "type": "shell", "group": { "kind": "test", "isDefault": true }, "promptOnClose": true, "problemMatcher": "$msCompile" }, { "label": "dotnet pack", "detail": "Pack the currently opened .NET project.", "command": "${workspaceRoot}/dotnet.sh", "args": [ "pack", "${file}" ], "windows": { "command": "${workspaceRoot}\\dotnet.cmd" }, "type": "shell", "promptOnClose": true, "problemMatcher": "$msCompile" } ] } ``` cc @dotnet/runtime-infrastructure @danmoseley @ManickaP

Author:	ViktorHofer
Assignees:	-
Labels:	`discussion`, `area-Infrastructure`, `untriaged`, `dev-innerloop`
Milestone:	-

[ViktorHofer]

Given that VSCode now has first class support by leveraging the .NET project system, this issue can be closed.