Debug .NET Core with docker containers

[MichaelSimons]

[Copied from https://github.com/dotnet/dotnet-docker/issues/185]

What is the proper way to install the debugger on a dotnet image and get it debugging from VSCode?

Currently there are multiple (messy) ways to work with old project.json and containers like for example, that bunch of scripts generated by yo docker.

Is there any guidance on how to create a debug container for .net apps?

Thank you
@galvesribeiro

[MichaelSimons]

For my own exercise, I went through the yo docker experience. Even though it was out of date, I was able to get it working with a few tweaks.

1. mkdir DockerDebugApp
2. cd DockerDebugApp
3. dotnet new -t Console1.1
4. yo docker (used defaults)
5. Ignore project.json file does not exist error
6. Open DockerDebugAdd in VSCode
7. add the following to the csproj

         <ItemGroup>
     <None Update="Dockerfile">
       <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
     </None>
     <None Update="Dockerfile.Debug">
       <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
     </None>
     <None Update="docker-compose.yml">
       <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
     </None>
     <None Update="docker-compose.debug.yml">
       <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
     </None>
   </ItemGroup>
   

8. Update the two Dockerfiles to reference the appropriate base images
   a. microsoft/dotnet:1.1-sdk-msbuild
   b. microsoft/dotnet:1.1-runtime
9. Update the Dockerfile.debug to install unzip before the GetClrDbg logic

       RUN apt-get update \
       && apt-get install -y --no-install-recommends \
           unzip \
       && rm -rf /var/lib/apt/lists/*
   

10. Set the $framework variables of the dockerTask script to match your csproj
    a. netcoreapp1.1
11. dotnet restore -r debian.8-x64
12. Build
13. Set breakpoint in program
14. F5

[galvesribeiro]

Hey @MichaelSimons

I got it to work. However there are limitations with the current approach:

1. yo docker assumes you are working/testing a single container within a single project. Scenarios like Docker Compose(d) apps which has multiple processes/containers is not supported.
   1.1 To workaround that I have to create a solution level compose file and make it spin all the containers described there. That makes the composability to work, but you have to manually attach a debugger to each container.
2. We can't have multiple containers of the same service being debugged unless you duplicate the launch block in launch.json
   2.1 e.g if you are scaling the service to more than one instance, you can't attach a debugger to the other instances. This issue I wasn't able to workaround.

I think those two painpoints are a joint work between the generator-docker and the VSCode debugger...

[matthewjcooper]

We also, need the the docker file to load the new 1.8 C# extension debugger. From (https://github.com/OmniSharp/omnisharp-vscode/blob/v1.8.0/CHANGELOG.md)

Remote debugging breaking changes: as part of our new architecture, there are a few breaking changes to the way remote debugging works.

vsdbg vs. clrdbg: As part of the new architecture, clrdbg has been replaced with a new executable named vsdbg. As such, the script to download vsdbg has changed to http://aka.ms/getvsdbgsh. Run curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg to download. See the wiki for more information.
Pseudo-tty's are no longer supported: previously we were a little more tolerant of pseudo-tty's transforming the input/output from the remote debugger. We are currently not as tolerant. If you are using ssh or plink as a pipe program, pass -T to fix this. If you have another transport and you are no longer able to connect, let us know and we can fix this for a future release.
debuggerPath is now required - previously the debuggerPath property of pipeTransport was recomended but not required. As part of this change we are now requiring it.

[galvesribeiro]

@matthewjcooper I had the precisely same problem yesterday. Had to change everything to use vsdbg because my projects were all broken.

[matthewjcooper]

@galvesribeiro would you mind sending me what you did to get working, i'm having issues.

[galvesribeiro]

@matthewjcooper I'm not using this template anymore because it is very limited and rely on external and platform specific issues. So what I have is:

Dockerfile:

FROM microsoft/dotnet:1.1-sdk-msbuild
ENV NUGET_XMLDOC_MODE skip
WORKDIR /vsdbg
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        unzip \
    && rm -rf /var/lib/apt/lists/* \
    && curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /vsdbg 
WORKDIR /app
ENTRYPOINT ["tail", "-f", "/dev/null"]

Solution level docker-compose.yml

version: '3.1'

services:
  YOU_PROJECT:
    image: YOUR_PROJECT:debug
    build:
      context: ./src/YOU_PROJECTDIRECTORY_HERE/bin/PublishOutput/
      dockerfile: Dockerfile.debug
    ports: 
      - "10200:10200"
    environment: 
      - ASPNETCORE_ENVIRONMENT=Development
    volumes: 
      - ./src/YOU_PROJECTDIRECTORY_HERE/bin/PublishOutput/:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro

VSCode tasks.json

{
    "version": "0.1.0",
    "command": "dotnet",
    "isShellCommand": true,
    "args": [],
    "tasks": [
        {
            "taskName": "publish",
            "args": [
                "${workspaceRoot}/YOUR_SOLUTION.sln", "-c", "Debug", "-o", "bin/PublishOutput"
            ],
            "isBuildCommand": true,
            "problemMatcher": "$msCompile"
        }
    ]
}

VSCode launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "YOUR_PROJECT",
            "type": "coreclr",
            "request": "launch",
            "cwd": "/app",
            "program": "/app/YOUR_PROJECT.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/src/YOUR_PROJECTDIRECTORY"
            },
            "pipeTransport": {
                "debuggerPath": "/vsdbg/vsdbg",
                "pipeProgram": "/bin/bash",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "-c",
                    "docker exec -i YOUR_PROJECT_1 /vsdbg/vsdbg --interpreter=vscode"
                ]
            }
        }
    ]
}

To make it work:

1. Build your project which will actually publish the files to output (I had to publish because my app requires load assemblies via reflection and the new .Net core runtime fail if I run directly from bin/debug without publish)
2. Open a terminal to the solution directory
3. Do a docker-compose build -> This need to be done only once if you change the container image
4. docker-compose up -d -> This is only required once since the container will kept alive between debug sessions. Only need do it again if you tear down the container.
5. Hit F5 on your project -> That will run the app inside the container and attach a debugger to it.

Every time you make change to the code you just need to build the project again (which will effectively publish whole solution) and run. Note that you can run multiple projects but not at same tiem. For wharever reason the VSCode setting to start multiple projects don't work while remote debugging. That doesn't prevent you to hit Start button in the second config so both debugger are running live.

Limitations: You can't use docker-compose scale yourservice=12 because you can't attach the debugger to multiple containers. This is a VSCode limitation, not docker, neither that settings.

Note that I'm not using any magical .sh or .ps1 to make things to work. Just pure VSCode config and docker. You should be able to add windows support on this config by just add that platform specific overrides on launch.json.

Let me know if you have any issues.

UPDATE: I forgot to mention that you must be on VSCode with the C# extension on version 1.8.0 or superior. If for whatever reason you need to keep pre-1.8.0, please update the example to use clrdbg instead of vsdbg.

[galvesribeiro]

Also, that config circumvent all limitations of the Docker extensions of VSCode since it only adds the syntax highlight so you don't need it if you don't want and is more flexible than recent released VS2017 Docker tools which is a lot more limited.

[matthewjcooper]

Wow, thanks for the quick reply, I’ll give this a shot!

[matthewjcooper]

This is working great. I also added "preLaunchTask": "publish", so I don't forget to rebuild when I make changes.

[galvesribeiro]

Yeah, I forgot to mention that... The preLaunchTask was intentionaly removed because we don't always need to build the project in order to run, because most of the changing code is compiled at runtime inside our project. So we preferred speed up the F5 :)

Glad it worked!

[matthewjcooper]

Last issue i'm having, is that the problem matcher is showing the problems, but clicking on them is not able to find the actual source file to pull up. Is there a way to change the cwd path for the problem matcher?

"problemMatcher": "$msCompile"

[galvesribeiro]

Hummm... No idea... Is that really related to the debugger? Because IIRC it is related to the compiler and language services, right?