AWS Serverless how to use "sam local start-api" to debug .net core 3.1 applications

Question

I would like to start serverless application locally and then debug it using Visual Studio. I see command line arguments --debug-port, --debugger-path, --debug-args and --debug-function, but no example of how these can be used for .net core.

Answer 1

To build on Lee Gunn's answer, see the following Github PR and follow up issue which go into more detail on how his launch configuration should work.

There seems to be some contention on whether or not this is working well. I have been trying to get this to work myself with no working results. My project is .Net 6 running on the default SAM linux container.

https://github.com/aws/aws-sam-cli/blob/develop/designs/dotnetcore-debugging.md

https://github.com/aws/aws-sam-cli/issues/941

UPDATE

I was eventually able to get this setup working by starting the SAM tool then attaching to the running .Net program inside the container.

A few things I initially missed which Lee also called out.

1. As Lee said, be sure to pass the --debugger-path parameter to AWS SAM with your host directory that contains vsdbg. It will mount that directory inside the Lambda container SAM creates. See the tasks.json for the path I found the mounting point at.

2. I ran into issue figuring out which process to attach to. Changing the ProcessId field froma defined value to ${command:pickProcess} allows VSCode to inspect the container at runtime so you can select the correct process, which WAS NOT ProcessId 1.

3. You can either use the --warm-containers EAGER to have the all containers (one for each lambda) start and look for the debugger or use LAZY and just pass a request to the SAM local server. The container will then spin up and wait for the debugger. Using EAGER resulted in too many containers being spun up in my case.

4. I had to update my PowerShell past v5, see the linked Github issue discussion.

launch.json

  "version": "0.2.0",
  "configurations": [
{
      "name": "Local start-api",
      "type": "coreclr",
      "request": "attach",
      "processId":"${command:pickProcess}",
      "pipeTransport": {
        "pipeProgram": "pwsh",
        "pipeArgs": [ 
          "-c",
          "docker exec -i $(docker ps -q -f publish=6000) ${debuggerCommand}"
        ],
        "debuggerPath": "/tmp/lambci_debug_files/vsdbg",
        "pipeCwd": "${workspaceFolder}",
      },
      "sourceFileMap": {
        "/var/task": "${workspaceFolder}"
      }
    }
  }
]

tasks.json

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "start-api",
      "type": "shell",
      "isBackground": true,
      "command": "sam",
      "args": [
        "local",
        "start-api",
        "-d",
        "6000",
        "--template",
        "./cdk.out/<Path To>template.json",
        "--debugger-path",
        "<Path to>/vsdbg",
        "--warm-containers",
        "LAZY"
      ]
    }
  ]
}

Also I chose not to run the SAM startup command as a preLaunchTask as there is no default problemMatcher to allow the actual debug task to continue after SAM does startup. It just hangs waiting for the preLaunchTask to complete.

An additional note is that I didn't end up using this as AWS SAM only supports API Gateway emulation in Proxy Lambda integration mode. I was actually hopping to test the Non Proxy Integration to troubleshoot some API Gateway parameter mapping issue.