Dotnet commands Permission Denied

superman-lopez commented 3 years ago

In the vscode project below issue was posted:

Issue Type: Bug

When debugging a dotnet core 3.1 project through vscode I get the following error. I've checked that the project files have the correct permissions, have tried running vscode with sudo, and reinstalled vscode without fixing this issue.

Rolling back to the previous version [of vs code] fixed the issue, so this appears to be caused by the latest update.

execvp(3) failed.: Permission denied
The terminal process "dotnet 'build', '/Users/a0793132/Documents/services/broker-service/api/BrokerService.API/BrokerService.API.csproj', '/property:GenerateFullPaths=true', '/consoleloggerparameters:NoSummary'" failed to launch (exit code: 1).

https://github.com/microsoft/vscode/issues/123324

vscode developers suggest this issue is caused by C# extension, however the issue can resolved by downgrading vscode. Not sure how execvp is triggered, but this may be a cross project issue.

JoeRobich commented 3 years ago

@superman-lopez So this failure is occuring when VS Code is executing the build task defined in your .vscode/tasks.json. Could you try changing the "type" of the build task from "process" to "shell" and trying again on the latest VS Code?

superman-lopez commented 3 years ago

@JoeRobich thanks, after changing the type to "shell" the debugger starts without issue. When I have the C# extension recreate the tasks.json, the default type in the new file is also "process".

RileyMShea commented 3 years ago

I also currently experiencing this issue.

Making @JoeRobich 's suggested change from "process" -> "shell" allows the debugger to work as expected.

Regenerating the Tasks.json with the extension, either via command pallete .NET generate assets or automatically via detecting a new project still defaults to a tasks.json build of type "process". This requires each newly created tasks.json to be manually changed from "process" to "shell" for debugging to work.

Error Message

> Executing task: dotnet build /home/riley/RiderProjects/ConsoleApp7/ConsoleApp7/ConsoleApp7.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary <

execvp(3) failed.: Permission denied
The terminal process "dotnet 'build', '/home/riley/RiderProjects/ConsoleApp7/ConsoleApp7/ConsoleApp7.csproj', '/property:GenerateFullPaths=true', '/consoleloggerparameters:NoSummary'" failed to launch (exit code: 1).

Running the same command from the command line works fine. I'm assuming that's why changing the task type to shell fixes the issue.

C# Extension generated tasks.json build section

...
 {
            "label": "build",
            "command": "dotnet",
            "type": "process",
            "args": [
                "build",
                "${workspaceFolder}/ConsoleApp7/ConsoleApp7.csproj",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary"
            ],
            "problemMatcher": "$msCompile"
        },
...

Vscode "About" info

Version: 1.60.2 Commit: 7f6ab5485bbc008386c4386d08766667e155244e Date: 2021-09-22T12:01:43.795Z Electron: 13.1.8 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Linux x64 5.4.0-86-generic

Extension Info

C# from Microsoft: v1.23.15

Dotnet Info

.NET v5.0.401

JoeRobich commented 3 years ago

@gregg-miskelly Do you know of any reason we couldn't update our asset generation to use "process" instead of "shell"? Some users do not seem to be able to debug without it, but I am uncertain if it would cause issues in other scenarios.

gregg-miskelly commented 3 years ago

I am not an expert on this, but I would say:

I don't fully know the ramifications of always running in the shell. One problem is that it will be a bit slower on every build since presumably we are going to pay the cost of starting the shell. I don't know how much of a problem this is -- it could be not worth it since 99% of folks don't run into it, but now everyone is paying the price of starting the shell, or it could be totally worth it because the cost is entirely trivial.
It seems like this might be a bug in VS Code's PATH decoding

superman-lopez commented 2 years ago

I just started a brand new project, and still the same issue comes up for me.

cpozos commented 2 years ago

In macOS Monterrey it is also happening. It is fixed using shellinstead of process as type

dotnet / vscode-csharp