
In my example, I will use a Docker image of TheCodingMachine created by David Négrier. You can do this by downloading the vsdbg package for the distro your image is based off (Ubuntu, Alpine, ARM, etc.To follow this tutorial, you must have the Xdebug extension installed on your container. When I shared this post internally my colleague Shayne Boyer brought up an idea on how to tackle this without adding a new layer to your Dockerfile, and in fact, making it possible to debug pre-built images (assuming they have the debugging symbols in them). Happy debugging! 😁 Bonus Idea: Removing the additional layer with volumes

In fact, I’m using this to debug an F# application I’m building to run on. There are more advanced scenarios you can tackle with this including debugging via SSH, all of which are covered on OmniSharp’s wiki.

ConclusionĪnd there you have it, you can now use VS Code as your editor of choice and also debug applications running in Docker containers. Now if you run your container and then launch the debugger in VS Code you’ll be able to pick the dotnet process within the container that your application is using. Under the hood it will execute docker exec -i /vsdbg/vsdbg to list the processes within the container, but we’ll do it a little bit nicer: Well, thankfully the process picker dialogue is capable of executing a command to get the list of processes and can do it against a remote machine. NET Core process.īut wait, that’s running in a Docker container, how do I pick that process? This will cause VS Code to launch the process picker and allow us to pick our. We’re going to add a new entry to our launch.json file that is of "type": "coreclr" and "request": "attach". Now our image has the debugger installed into it we need to setup VS Code to attach to it.

This downloads a sh script from and pipes it straight to /bin/sh for execution and provides a few arguments, most importantly the /vsdbg which is where the remote debugger will be extracted to. Curl -sSL | /bin/sh /dev/stdin -v latest -l /vsdbg
