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
Gutemberg Ribeiro (@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 Michael Simons (@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]

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

[matthewjcooper]

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

[galvesribeiro]

Matthew Cooper (@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?

[matthewjcooper]

You are right, not related to debugging, just how to link compile errors/warning with the vscode problems window. Nvm on that one.

[hartmannr76]

It would be nice if there was a sample project setup to include these changes, or even a forked repo to demonstrate this.

I had hoped that this project would've resolved this by now, but it seems like that is not the case. Anyone willing to set something up that they have working or work on forking this? I'd be willing to chip in, but running these instructions; when attaching to debugger, it looks like VSCode just keeps doing something and sits in limbo.

[PaluMacil]

I'm pretty early in my understanding of Docker, as is my team, but right now we develop locally, then deploy to a local docker and then deploy to production (process simplified--there's a but more change and source control involved). We'd certainly love to do away with that first phase and simply do everything always in Docker, and despite all of us having MSDN accounts, almost all of us have moved from VS to VS Code. It's wonderful besides the debugging within Docker part. 👍