Integrated Docker Compose Debugging for .NET Core

[philliphoff]

Support debugging Docker containers created via Docker Compose

[raix]

@philliphoff being able to debug a dotnet core instance using docker-compose is valuable with dealing with a more complicated setups - both from the point of starting up the environment but also using attach. Let me know if you need help on this issue.

[julielerman]

Thought I would leave this link here for anyone looking to see how to debug with docker-compose in the meantime :) https://www.richard-banks.org/2018/07/debugging-core-in-docker.html :)

[DatXN]

Pumb for this very necessary feature.

[chazt3n]

Is any work being done on this? If not, how can I help?

[bwateratmsft]

@chazt3n Not at the moment but it is on our radar. At the moment, @philliphoff and I are doing a major refactor of debugging. It is primarily centered around single-Dockerfile debugging, but the model would certainly support docker-compose debugging. You can see our PR here: #1245

[chazt3n]

@bwateratmsft - wonderful, thank you - checking it out

[BigMorty]

We have improved the Compose scaffolding and debugging story when using the attach debugger model. See this help document for more information - https://code.visualstudio.com/docs/containers/docker-compose

[mattjbrent]

its been well over a year - is there at least a timeline on this? it would be great to get better support. Currently Docker support for .net core and microservices is poor between both vscode and visual studio. Encountering a ton of ssl cert issues when locally developing in VS for Mac.

Trying to get debugging working in vscode is more complicated than architecting our microservices it feels like.

[BigMorty]

Hello @mattjbrent I am the lead PM for the container tools in VS, VS Code, and VS for Mac. Regarding debugging multiple .NET Core microservices in VS Code, have you looked at our recently updated documentation that uses Docker Compose? It can be found here - https://code.visualstudio.com/docs/containers/docker-compose.

I would like to know if you or anyone else interested in this topic to make time for us to chat on a call? It would be great to take 30-45 minutes for my team to understand how you go about building cloud native apps/microservices and what problems/pain points you are experiencing. Please email me at mike.morton@microsoft.com if anyone is willing to discuss.

[chazt3n]

@BigMorty wow thank you for such a kind offer - we have had reasonably good luck with the .dcproj files in what I call "big visual studio"

I haven't really dived (dove? diven?) into the experience in vs code as I expected the .dcproj to work.

I've heard that docker-compose with vs code does in fact work but I unfortunately haven't had time - I will check out your documentation link above, just wanted to mainly thank you for reaching out and working to improve end user experience

[bwateratmsft]

It's definitely possible to debug using compose, just a question of complexity. VSCode + the Docker extension + the C# extension have everything they need to do debugging.

It's worth noting, VSCode itself doesn't really care about projects/solutions--including dcprojs. .NET itself still needs csprojs, of course.

To set up debugging for compose, you'd want a regular and a debug compose file. You'd also need to set up a launch configuration for each service you want to debug. It is possible to debug multiple services with one F5, VSCode calls that a compound launch configuration. I believe @ucheNkadiCode is currently working on a more exhaustive guide on how to actually make this happen.

[BigMorty]

Thanks @chazt3n for replying, I look forward to hearing your feedback after trying Compose with our VS code Docker extension. Again, if anyone on or interested in this thread wants to get on a call with me and @bwateratmsft we are more than happy to do so. We can talk bout what you are building and how our tools could make it easier.

Please email me at mike.morton@microsoft.com if anyone is willing to discuss.

[mattjbrent]

@BigMorty @bwateratmsft I really appreciate you reaching out here. I'd more than happy to chat on a call or even just exchange some emails.

A lot of people a lot more brighter than i am have worked on this stuff - and i'm sure there's a lot of ways to do this, and perhaps even a right way. However having being invested in this at a technical level for about a month, I feel like there's a big leap between the current docs and implementation in some pretty common scenarios. Of course this is still relatively new stuff so gaps are understandable.

As I said, if i can contribute any kind of a discussion in a meaningful way that might help people in the same position that i found myself in, im happy to have a chat.

I would like to add, i did manage to get a full proof-of-concept working that my team are now starting to develop on. So if anyone stumbles across this thread on here and would like to know how we approached it, feel free to reach out.

[BigMorty]

Thanks @mattjbrent for the willingness to chat with us. I just saw the email you sent as well. I will send you and invite next week.

[nathansegers]

I have experimented with docker-compose and debugging a dotnet application (.NET 5.0) and it works fine with the tutorial followed here: https://code.visualstudio.com/docs/containers/docker-compose#_net

I'm quite happy with the result.

[domshyra]

I followed the Docker Compose .net tutorial for .net, but can't seem to load my code. My breakpoints are in fact hit, but the CS file is blank(says untracked in vscode).

One thing I did notice is I was never prompted for "you're asked if you want to copy the debugger (vsdbg) into the container" in vs code.

The api is a .net core minimal api. written in .net 6. The web is a Create React App.

below is the docker-compose.debug.yml

version: '3.4'

services:
  web:
    image: web
    build:
      context: Web
      dockerfile: ./Dockerfile
    environment:
      NODE_ENV: development
    ports:
      - 3000:3000
      # - 9229:9229
    # command: ["node", "--inspect=0.0.0.0:9229", "index.js"] #TODO: figure out how to attach debugger
  api:
    image: api
    build:
      context: Api
      dockerfile: ./Dockerfile.debug
    ports:
      - 8000:80
      - 8001:443
    restart: always
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=https://+:443;http://+80
      - ASPNETCORE_HTTPS_PORT=8001
      - ASPNETCORE_Kestrel__Certificates__Default__Password=<CREDENTIAL_PLACEHOLDER>
      - ASPNETCORE_Kestrel__Certificates__Default__Path=/https/api.pfx
    volumes:
      - ~/.vsdbg:/remote_debugger:rw # this was added by VScode creating a docker compose

here is my lauch.json task

{
    "name": "Docker .NET Attach (Preview)",
    "type": "docker",
    "request": "attach",
    "platform": "netCore",
    "sourceFileMap": {
        "/src": "${workspaceFolder}"
    }
 },

I've also tried this version of the to the lauch.json task since in my compose I have the remote_debugger as a volume which vscode generated for me when creating a docker compose file for my api.

{
    "name": "Docker .NET Attach (Preview)",
    "type": "docker",
    "request": "attach",
    "platform": "netCore",
    "sourceFileMap": {
        "/src": "${workspaceFolder}"
    },
    "netCore": {
        "debuggerPath": "/remote_debugger/vsdbg"
    }
 },

Both launch settings produce the same results of being able to step, but not see the code. Any suggestion how to get the cs file tracked when debugging?

Edit: I found my issue was the that it would add the program.cs file to my root folder when infact I have an Api folder that program.cs lives in. Pointing it to where that code lives in the src solved this invisible file issue for me

"sourceFileMap": {
        "/src": "${workspaceFolder}/Api"
    },

[bwateratmsft]

@domshyra if I had to guess it's either an issue with source maps (but the "Docker .NET Attach (Preview)" task already has a value for that), or, the debugger is struggling because the binaries are release-built instead of debug-built. What is in your Dockerfile?

[domshyra]

@bwateratmsft it was just that. Thanks! Once I fixed the source map location it worked correctly. It was just such a strange behavior. I added an edit to my original post to hopefully help anyone else that runs into this issue.