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

[NicolasReyDotNet]

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]

I believe the Docker extension adds support for setting up your docker containers to support debug launch.

[NicolasReyDotNet]

I believe the Docker extension adds support for setting up your docker containers to support debug launch.

I'm sure you're right, but following the official documentation didn't mention it, all I see is the following

then in step 4 when launching the docker-compose up command, the application is launched as well, attaching the debugger is necessarily launched too late then.

Do you have any idea on how I could make it works ?

[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]

@gregg-miskelly the article referenced is focused on docker-compose. Right now our only supported story for that is to launch it manually and then attach.

We have an issue to add "real" compose debugging (https://github.com/microsoft/vscode-docker/issues/840), and we also have the "real" non-compose debugging documented (https://code.visualstudio.com/docs/containers/quickstart-aspnet-core).

The article @NicolasReyDotNet referenced does mention the need to install the Docker extension (but it is installed per the original comment): https://code.visualstudio.com/docs/containers/quickstart-aspnet-core#_prerequisites

Docker and the VS Code Docker extension must be installed as described on the overview.

[NicolasReyDotNet]

@gregg-miskelly I'll give a try to wait for the debugger to be attached, thank you

@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]

@gregg-miskelly
It worked, thank you.

I'll use this method and get in touch for a solution supplied for VSCode

[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

[NicolasReyDotNet]

@bwateratmsft thank you for your help, it's very clear. I'll follow this evolution with interest