Remote process picker does not work (attach to Docker container scenario)

[karolz-ms]

Environment data

MacOS BigSur 11.4
.NET SDK 5.0.301
VS Code 1.57.0
C# extension 1.23.12
Docker extension 1.13.0
Docker Desktop for Mac version 3.3.3

OmniSharp log

Steps to reproduce

1. Create new web API project: dotnet new webapi --no-https
2. Open application folder in VS Code
3. When prompted, add "required build files" to workspace
4. Run Docker: add Docker files to workspace command. Select ".NET ASP.NET Core", Linux, port 5000, yes to optional Docker Compose files
5. Change first line of the Dockerfile so that it reads FROM mcr.microsoft.com/dotnet/aspnet:5.0-focal AS base (note the image tag is 5.0-focal, not just 5.0
6. Right-click Dockerfile and choose "build image"
7. Switch to Docker view (whale icon), right-click the application image (expand to see the "latest" tag), and choose "Run"
8. Open .vscode/launch.json and add the following debug configuration

{
    "name": "Docker .NET Core Attach",
    "type": "docker",
    "request": "attach",
    "platform": "netCore",
    "processId": "${command:pickRemoteProcess}"
}

9. Make the added debug configuration active and execute it. Select "Individual Containers" group, then the running application container. When prompted, allow debugger to be copied to the application container.

Expected behavior

After the debugger is copied to the application container, the user should be prompted to select the process to attach to.

Actual behavior

An error message that says "No process with the specified id is currently running"

Additional information

When Docker extension resolves the debug configuration, it will return the following:

{
  "name": "Docker .NET Core Attach",
  "justMyCode": false,
  "platform": "netCore",
  "processId": "${command:pickRemoteProcess}",
  "processName": undefined,
  "request": "attach",
  "type": "coreclr",
  "sourceFileMap": {
    "/src": "${workspaceFolder}"
  },
  "pipeTransport": {
    "debuggerPath": "/remote_debugger/vsdbg",
    "pipeCwd": "${workspaceFolder}",
    "pipeProgram": "docker",
    "quoteArgs":  false,
    "pipeArgs": [
      "exec",
      "-i",
      "application_container_name"
    ]
  }
}

(application_container_name is the name of the running application container)

This used to work until recently--the user would be prompted to select the process to attach to. I suspect #4509 might have broken this scenario.

FWIIW, the following launch configuration works as expected (assuming debugger bits have been already copied into the container):

       {
            "name": "Manual Docker attach",
            "type": "coreclr",
            "justMyCode": false,
            "processId": "",
            "request": "attach",
            "sourceFileMap": {
                "/src": "${workspaceFolder}"
            },
            "pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "pipeProgram": "docker",
                "pipeArgs": [
                    "exec",
                    "-i",
                    "application_container_name"
                ],
                "debuggerPath": "/remote_debugger/vsdbg",
                "quoteArgs": false
            }
        }

(leveraging the new functionality that prompts the user to select a process when processId is left empty)

[gregg-miskelly]

CC @WardenGnaw

[WardenGnaw]

Running:

{
  "name": "Docker .NET Core Attach",
  "justMyCode": false,
  "platform": "netCore",
  "processId": "${command:pickRemoteProcess}",
  "processName": undefined,
  "request": "attach",
  "type": "coreclr",
  "sourceFileMap": {
    "/src": "${workspaceFolder}"
  },
  "pipeTransport": {
    "debuggerPath": "/remote_debugger/vsdbg",
    "pipeCwd": "${workspaceFolder}",
    "pipeProgram": "docker",
    "quoteArgs":  false,
    "pipeArgs": [
      "exec",
      "-i",
      "application_container_name"
    ]
  }
}

Not seeing this repro on macOS M1 BigSur 11.2.1 or Windows x64. I was able to see the Select the process to attach to dialog.

[karolz-ms]

@WardenGnaw correct, when ${command:pickRemoteProcess} is used directly in launch.json, it works, but when it is used as part of return value from DebugConfigurationProvider.resolveDebugConfiguration() (debug configuration provider for Docker, implemented by the Docker extension), the command picker is NOT invoked as expected.

[WardenGnaw]

The idea of #4509 was to have multiple outputs since VS Code commands are only able to have a single output. We needed processId and arch to support debugging on Apple M1.

The idea now is that ${command:pickRemoteProcess} will return "" and if processId and processName are falsy, the process picker should run.

Is the configuration above not passed the the C# Omnisharp debugger?

[karolz-ms]

(please take the following with a grain of salt--I am not super familiar with how VS Code debugging works)

I think the problem is that, in the scenario described by the repro steps, is the Docker extension that "resolves" the debug configuration, not the Omnisharp extension. Since the logic to fill the processId via the picker was moved to the Omnisharp debug configuration resolution, and ${command:pickRemoteProcess} is just a stub returning nothing, the logic to show the picker is now bypassed and the final configuration does not have the processId filled.

[WardenGnaw]

I took a quick look at the flow in vscode-docker.

This might be that VS Code is happy with the resolution but the debug type changed and I dont think they call resolveDebugConfiguration again for the different type.

@isidorn @weinand Can you confirm this flow for VS Code?

We can bring back the listRemoteProcess command, but it will not be able to detect the architecture type and it will always use the x86_64 debugger which would fail the Apple M1 docker running arm64 containers.

[karolz-ms]

For the Docker extension use case the extension can inspect the image and add the arch property accordingly for arm64 images. Just restoring access to the process picker would unblock our scenario.

This might be that VS Code is happy with the resolution but the debug type changed and I don't think they call resolveDebugConfiguration again for the different type.

Yes, that is my understanding as well (and it is in line with the observed behavior).

[WardenGnaw]

The one possible VS Code issue here is that vscode-docker returns the configuration in resolveDebugConfiguration and since it returned the type coreclr it should invoke the C# Extension's resolveDebugConfigurationWithSubstitutedVariables.

If that is not how VS Code team expects it to work. we can bring back the command as listRemoteDockerProcesses.

[karolz-ms]

So @WardenGnaw what would be the plan here? Do you want to pursue the route of making VS Code re-resolve the debug configuration if type changes? Restore the listRemoterDockerProcess command? Something else?

This bug is kind of important for Docker extension to resolve, because all of our Docker Compose debugging functionality is based on attaching the debugger to running container...

[WardenGnaw]

Ideally they should fix the issue that resolveDebugConfigurationWithSubstitutedVariables is not being called for the configuration which has type: 'coreclr'.

It looks like this issue has been here for a while: microsoft/vscode#110889

[karolz-ms]

Ideally, yes, but microsoft/vscode#110889 is a new functionality, which may take a while for VS Code core to discuss and implement.

For our customers that are suffering from this regression today, can we get back access to the process picker please?

[WardenGnaw]

Created a PR for the temporary workaround.

[karolz-ms]

So @WardenGnaw just to make sure I understand the implications: when new OmniSharp release ships, the following configuration should work (changing pickRemoteProcess to pickRemoteDockerProcess):

{
    "name": "Docker .NET Core Attach",
    "type": "docker",
    "request": "attach",
    "platform": "netCore",
    "processId": "${command:pickRemoteDockerProcess}"
}

[WardenGnaw]

Yep. That is exactly the launch.json configuration I used for testing and got a process listing.

Here is the vsix of the omnisharp-vscode extension with the ${command:pickRemoteDockerProcess} supported.
csharp-1.23.13-pickDockerProcess.zip

[isidorn]

@WardenGnaw sorry for the slow response, I was on vacation.
If there is an issue with VS Code can you please write a gist of the discussion here so I do not have to read and compile the whole conversation :) Thanks

[weinand]

@isidorn I think the underlying issue is microsoft/vscode#110889

@WardenGnaw can you confirm this and would a fix for microsoft/vscode#110889 address this issue #4607?

If yes, then I suggest that VS Code will try to address microsoft/vscode#110889.

[WardenGnaw]

@isidorn Sorry the thread grew longer then when I pinged you.

The core issue is that the docker extension is using a omnisharp extension's command and we changed the functionality of it. The change on our end was to create a "command" that can return multiple configuration fields, and we did this by checking to see if they field was unset or empty for attach in resolveDebugConfigurationWithSubstitutedVariables.

The problem is that VS Code only calls docker's resolveDebugConfiguration and when they return a configuration that is coreclr, it never call's omnisharp's resolveDebugConfigurationWithSubstitutedVariables. Code

@weinand Yep. microsoft/vscode#110889 would fix this issue.

[isidorn]

@WardenGnaw Thanks for clarification. Then let's continue the discussion in microsoft/vscode#110889

[karolz-ms]

The original scenario was addressed with the change that @WardenGnaw made, so closing this issue (the more general issue microsoft/vscode#110889 remains)