Debugging in Containers

The container images can be started on demand to run the microservices. However, producing a new Docker image that internally builds and publishes release code won’t offer the debugging of the code we’re looking for!

To overcome this, we need to run the development code unpublished, using a Debug build, quickly and dynamically inside a container with a debugger attached. We must understand how Visual Studio modifies the container images to support debugging and how this fits into the overall orchestration of all components, including the service component.

Debugging individual microservices

While Visual Studio did a fantastic job setting up the Dockerfile for release builds, it doesn’t use this entire file definition when debugging code in a container.

The additional configurations added to the project enable exactly the kind of fast and dynamic environment we need. Under the project launch profiles, we should now see a new one added by Visual Studio called Docker.

Before we look to understand how Visual Studio manages to debug in containers, we first want to confirm the debugging does work. Select this new launch profile and press the “Debug” play button (or press the “F5” key).

In the container window, we’ll see a new running container named consumer based on the consumer:dev image. If we explore further, as expected, we’ll see noticeable differences between the running image and the Dockerfile definition.

Visual Studio has created a different image with a series of mapped volumes (including one to the local solution folder) and configured and attached a remote debugger.

We can stop the debugging session at any point, and the container will continue to run, even though the application process has stopped. We can add breakpoints and relaunch the debugging session as we would in any local debug session, knowing that the processes are instead running within a container. ...