Debugging ASP.NET Core apps in a local Docker container

Good news, everyone! Our latest Rider 2018.2 EAP (Early Access Preview) build comes with support for debugging ASP.NET Core apps in a local (Linux) Docker container. Being able to attach the debugger to a Docker container helps to validate our application locally in a Linux Docker container that should closely resemble production. Let’s see how this works!

Setting up Rider and Docker

Rider comes with Docker integration. We’ll have to configure Rider to connect to our local Docker daemon to enable it. Under Build, Execution, Deployment | Docker in the settings, we can add a new connection to Docker. Typically all we will need to configure is the engine API URL, which usually is tcp://localhost:2375.

Add Docker in Rider settings

Note that by default, Docker for Windows does not expose the daemon to Rider. This will have to be enabled in Docker’s settings:

Expose Docker daemon to Rider

Once configured, we can open the Docker tool window (View | Tool Windows | Docker) and inspect running containers, images, container logs and so on:

Docker tool window in Rider for managing containers and images

With that out of the way, let’s create a Docker run/debug configuration for our application.

Creating a Docker run/debug configuration

When opening an ASP.NET Core project containing a Dockerfile in Rider, a suggestion will be shown to create a new run/debug configuration for it:

Dockerfile detection

Doing so will create a new run/debug configuration. However, depending on the commands in our Dockerfile, it may be better to try building and running our container first. So let’s skip this step and find the Dockerfile in our project.

Rider comes with syntax highlighting and code completion, as well as the ability to Run on Docker.

Run application in Docker

Depending on the Dockerfile, this will either succeed or fail. When trying to run a Dockerfile that was generated with Visual Studio, chances are this first attempt may not work immediately, typically with an error similar to Failed to deploy ‘<unknown> Dockerfile: AcmeCorp.Web/Dockerfile’: COPY failed: stat /var/lib/docker/tmp/docker-builder109565895/AcmeCorp.Web/AcmeCorp.Web.csproj: no such file or directory. That’s okay: Rider’s Docker run configuration attempts to build the container from the project directory, whereas the Dockerfile generated by Visual Studio expects the container to be built from our solution folder. Let’s fix that!

From the toolbar, we can see Rider generated a new run/debug configuration. We can edit it and configure it further to accommodate our ASP.NET Core web application.

Rider toolbar displays new Docker run/debug configuration

First things first: if you’ve run into the error described earlier (COPY failed), make sure to set the Context folder to . (dot) – this will tell Rider to build the Dockerfile from the solution root folder. If you did not run into this error, there’s no need to change it!

Next, it’s always handy to have a recognizable container name, so let’s set the Container name to something that is related to our project. I chose acmecorp-web. Also make sure Run built image is checked.

One more thing to configure: port bindings. By default, ASP.NET Core will run our web application inside the container on port 80. We want to be able to access it, so we’ll have to create a port map that forwards traffic from a port on our local computer into the container. I’ve added a mapping from port 8000 to port 80.

Here’s the full Docker run/debug configuration:

Docker run configuration

Once we’ve completed this task, it’s time for the real work. Let’s debug our application!

Debugging our application in Docker

With the run/debug configuration in place, we can set a breakpoint somewhere in our application and start debugging by pressing F5 and selecting the Docker run/debug configuration. Rider will then build our container, run it and attach the debugger to it.

Just like with debugging on our local machine, Rider allows inspecting variables, the stack frames, threads, as well as stepping through code – both our own as well as decompiled third-party code.

Debugging in Docker in Rider

We can now start/stop/remove our container using the Docker tool window, as well as run and debug our application in a local (Linux) Docker container.

Known limitations

Right now, only debugging ASP.NET Core web applications on Linux Docker containers is supported. And while Rider allows debugging containers that are built from a Dockerfile, it does not yet support debugging containers that are created using Docker compose (docker-compose.yml).

Give this a try and download Rider 2018.2 EAP now! We’d love to hear your feedback on these improvements!

About Maarten Balliauw

Maarten Balliauw is a Developer Advocate at JetBrains, working on .NET tools and Space. He focuses on .NET, Azure, web technologies and application performance. Maarten is a frequent speaker at various national and international events. In his free time, he brews his own beer. Follow him on Twitter or check out his personal blog.
This entry was posted in How-To's and tagged , , , , . Bookmark the permalink.

37 Responses to Debugging ASP.NET Core apps in a local Docker container

  1. Nick says:

    Why isn’t debugging supported with container created using Docker compose? Is it a limitation of docker or rider?

  2. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #2625

  3. Pingback: Dew Drop - July 19, 2018 (#2769) - Morning Dew

  4. Bart Verkoeijen says:

    Just tried this out and it works great! Thanks for adding this support.

    Docker-compose support would be much appreciated as well. Hope this could be added in a future version.

    One hiccup I had was that debugging a microsoft/dotnet:2.1-sdk-alpine container fails, and the container crashes on startup. No errors in the log. Using microsoft/dotnet:2.1-sdk works fine though.

  5. Zhengbo Li says:

    I see the same thing, debugging on dotnet:2.1-sdk-alpine fails. On the dotnet:2.1-sdk image works fine.

  6. Stephan Kast says:

    Is there a Mac related tutorial available yet?

  7. Anders says:

    Hi Maarten.

    Is it possible to debug azure functions running in a container somehow ? I am able to run a container based on microsoft/azure-functions-dotnet-core2.0 , but debugging fails with:

    Failed to deploy ‘ Dockerfile: HelloWorld/Dockerfile’: com.github.dockerjava.api.exception.InternalServerErrorException: {“message”:”OCI runtime create failed: container_linux.go:348: starting container process caused \”exec: \\\”/riderDebugger/\\\”: stat /riderDebugger/ no such file or directory\”: unknown”}

    I am using Docker version 18.06.1-ce, build e68fc7a and Rider 2018.2.3


  8. Yuma says:

    Could the injected debugger be made available publicly?

    I have been successful in using VSCode to debug containerized dotnet applications by creating my own images which have an ssh server and vsdbg running, and subsequently connecting to the vsdbg over ssh.

    I would appreciate if a similar workaround could be made possible for Rider.

    • Yuma says:

      EDIT: This is so that we can use Rider to debug apps from docker-compose while you guys work on a more integrated approach.

    • Artem Bukhonov says:

      Hi! We’re in progress on remote debugging support which will work over ssh. So you will be able to attach to your app in container.

  9. Roman says:

    Hi. When I try to debug simple console Hello world app in container, i’v got this kind of error:
    Could not set breakpoint at location ‘C:\Users\РоманПриходько\source\repos\ConsoleApp2\ConsoleApp2\Program.cs : 9 (Object reference not set to an instance of an object)

    Pdb file is in the container. Container is successfully run, but all breakpoints are inactive.

  10. phil says:

    I am getting my breakpoints hit but it does not show any indication in the text editor on what line Im currently on. After stepping with F10, i can’t tell where I am at in the code. The only indication of something wrong is a popup that says could not get symbols.

    This is on latest mac OS rider version 2018.3.3

  11. kodbuse says:

    Is there any way to attach the debugger to an already running Docker container? Like others, I’m trying to debug a container in an application stack created with docker-compose. However, I don’t necessarily need the IDE to manage any of that for me, if it’d just let me run “docker-compose up” on the side in a terminal and then attach the Rider debugger to my container of choice. I understand that I might need to modify the image to add some debugging tools, which is fine.

Leave a Reply

Your email address will not be published. Required fields are marked *