Question : How to debug my Startup.cs within docker-compose ? (debugger is attached too late)

Issue Description

Hi, I managed to debug an asp .net core 3.1 application within an Ubuntu WSL-2 distro (on Windows 10), using a docker-compose file thanks to this Vs code tutorial, but I can’t figure out how to debug early executed files like Program.cs or Startup.cs, the breakpoints are never hit in this files.

We start the container using a docker-compose up command, then we attach the debugger, all breakpoints set in Program.cs or Startup.cs are not hit. Indeed the app has already pocessed these files when I manually attach the debugger, it’s too late. All other breakpoints (in controllers or background process …) are hit as expected.

When debugging the same project with Visual Studio 2019 Community, all my breakpoints are hit, even those in Program.cs or Startup.cs which is the expected behavior here, indeed I guess the container is already up when we attach the debugger in VS Community, that’s the main difference.

What am I doing wrong ?

I also tried to attach the debugger before the container is launched, which indeed fails : no process exist to be linked with the debugger

Error: Process 'docker exec -i "myapp...' exited with code 1
Error: Error: No such container: myapp

Steps to Reproduce

Set a breakpoint to any line in Startup.cs

Create a dockerfile in the project we want to debug

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["src/myapp/src/v.csproj", "src/myapp/src/"]

RUN dotnet restore "src/myapp/src/myapp.csproj"  -nowarn:msb3202,nu1503 --verbosity diag
COPY . .
WORKDIR "/src/src/myapp/src"
RUN dotnet build "myapp.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "myapp.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "myapp.dll"]

Create a docker-compose.debug.yml file

version: '3.7'

services:
  myapp:
    image: myapp
    container_name: myapp
    build:
      context: .
      dockerfile: src/myapp/src/Dockerfile
    ports:
      - "60713:80"
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:80
    volumes:
      - ~/.vsdbg:/remote_debugger:rw
networks:
    default:
      external:
         name: mynetwork

Create a debug configuration (launch.json)

{
   "version": "0.2.0",
   "configurations": [
       {
           "name": "Docker .NET Core Attach (Preview)",
           "containerName": "myapp",
           "type": "docker",
           "request": "attach",
           "platform": "netCore",
           "sourceFileMap": {
               "/src": "${workspaceFolder}"
           }
       }
]
}

Then Launch the file (docker-compose -f "docker-compose.debug.yml" up -d --build)

Finally attach the debugger using the dedicated button

Expected Behavior

I expect the breakpoints set in Startup.cs to be hit (this file is processed before I attach the debugger, as soon as the docker-compose command is played)

Actual Behavior

All breakpoints set in Startup.cs are not hit, but breakpoints in long process like Background services or in a controller are hit as expected (they are processed after I attach the debugger)

Logs

No log, as it’s not a error, nor an exception

OmniSharp log

No log, as it's not a error, nor an exception

C# log

No log, as it's not a error, nor an exception

Environment information

VSCode version: 1.50.1 C# Extension: 1.23.4

Mono Information

OmniSharp using built-in mono

Dotnet Information

.NET Core SDK (reflecting any global.json): Version: 3.1.403 Commit: 9e895200cd

Runtime Environment: OS Name: ubuntu OS Version: 20.04 OS Platform: Linux RID: ubuntu.20.04-x64 Base Path: /usr/share/dotnet/sdk/3.1.403/

Host (useful for support): Version: 3.1.9 Commit: 774fc3d6a9

.NET Core SDKs installed: 3.1.403 [/usr/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.App 3.1.9 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs: https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension	Author	Version
csharp	ms-dotnettools	1.23.4
vscode-docker	ms-azuretools	1.7.0

[gregg-miskelly]

The official documentation doesn’t provide a path to launching under the debugger - just attaching. I don’t know if this is intentional or not. @bwateratmsft do you know why the article that Nicolas referenced doesn’t suggest using the Docker extension? Is it just out-of-date with best practices, or is there some reason one might want to do things that way?

If you do NOT want to use the Docker extension for some reason, the only way to debug startup code is to add something like: while (!Debugger.IsAttached) { Thread.Sleep(100); } to the beginning of your startup code so that it will not proceed until a debugger is attached.

[bwateratmsft]

@bwateratmsft Ok great, I felt alone with my use case, I’m glad it’s referenced at Microsoft. Do you have any roadmap on it ? Is it the same for other languages ? (Python, Node.js … ) Thank you

@NicolasReyDotNet Yes, we have debugging support for Python and Node.js in addition to .NET. For all three, there’s a “simple” debugging experience that doesn’t involve docker-compose–just F5 and go–and a “less simple” debugging experience that involves compose up’ing a docker-compose.debug.yml file (which we scaffold for you), and then using a remote attach configuration to attach a debugger. One could easily set a preLaunchTask in the launch config that would compose up the docker-compose.debug.yml, in order to avoid having to do that manually, and/or a postDebugTask to compose it back down (more on those options here).

Python simple: https://code.visualstudio.com/docs/containers/quickstart-python Node simple: https://code.visualstudio.com/docs/containers/quickstart-node .NET simple: https://code.visualstudio.com/docs/containers/quickstart-aspnet-core

docker-compose debugging (all three): https://code.visualstudio.com/docs/containers/docker-compose#_debug

We do plan on making a simpler debugging experience for docker-compose, more like the “simple” we have now for non-compose: https://github.com/microsoft/vscode-docker/issues/840, https://github.com/microsoft/vscode-docker/issues/1294