Debugging ASP.NET Core apps in a local Docker container

Maarten Balliauw

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!

Comments below can no longer be edited.

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

  1. Nick says:

    July 18, 2018

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

    • Maarten Balliauw says:

      July 18, 2018

      Docker compose would require us to rewrite the docker-compose.yml to inject the debugger executable and configuration. It’s in our plans, but not there yet.

      • Nick says:

        July 18, 2018

        Interesting! I think Microsoft has the same issue in Visual Studio.

        Thanks for sharing.

      • Ryan O'Dell says:

        July 18, 2018

        @Maarten Balliauw – this looks possible:

      • Ricky says:

        July 18, 2018

        Why does it need to rewrite the docker-compose? If we’ve already included the vsdbg in the image (I do this by default in development images), shouldn’t it just be an “Attach to container”? Setting this up for VSCode is pretty trivial. I can send a sample repo I use if that helps

        • Maarten Balliauw says:

          July 19, 2018

          Good question, the answer can be found in history…

          (or in the message that is displayed when launching vsdbg -> “You may only use the Microsoft .NET Core Debugger (vsdbg) with Visual Studio Code, Visual Studio or Visual Studio for Mac software to help you develop and test your applications.”)

          In short: we have no other option than to inject our own debugger.

          • Ricky says:

            July 19, 2018

            Ah, I did not see the `vsdbg` log message until now. However, it does look like I could instead install `clrdbg` which does seem to be open source. I read the other Rider article and it seems like what had a license restriction was the interface from a product like Visual Studio -> Debug app. Either way, it would be nicer to instead just perform a similar action (i.e. I would fetch the JetBrains debugger when building my image) than to have an IDE override my Docker config. Deploying the instance and wanting to attach after the fact is going to be my 99.99% use case. It’s my only hard limitation for wanting to use Rider 100% of the time developing .NET Core apps

            • Maarten Balliauw says:

              July 19, 2018

              Thanks Ricky! Will log internally.

              • Rodrigo Boratto says:

                March 14, 2019

                Any news about it?

              • Maarten Balliauw says:

                March 14, 2019

                Not currently

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

    July 19, 2018

    […] Debugging ASP.NET Core apps in a local Docker container – Maarten Balliauw […]

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

    July 19, 2018

    […] Debugging ASP.NET Core apps in a local Docker container (Maarten Balliauw) […]

  4. Bart Verkoeijen says:

    August 24, 2018

    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:

    August 24, 2018

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

  6. Maarten Balliauw says:

    August 27, 2018

    Thanks both Just logged an issue here:

  7. Stephan Kast says:

    August 30, 2018

    Is there a Mac related tutorial available yet?

    • Maarten Balliauw says:

      August 31, 2018

      Hi Stephan, what type of tutorial are you looking for? Docker or Rider in general?

  8. Anders says:

    October 3, 2018

    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


  9. Yuma says:

    October 10, 2018

    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:

      October 10, 2018

      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:

      October 10, 2018

      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.

  10. Roman says:

    January 11, 2019

    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.

    • Maarten Balliauw says:

      January 11, 2019

      Hi Roman, this is a known bug that will be fixed in Rider 2018.3.2 soon.

  11. phil says:

    February 18, 2019

    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

    • Maarten Balliauw says:

      February 25, 2019

      Can you double check the app is compiled in Debug mode and not Release?

      • matt durham says:

        May 14, 2019

        Also getting this same error, application is built with -c Debug

        • Maarten Balliauw says:

          May 15, 2019

          Is this with 2019.1 ?

          • Jason Rai says:

            May 15, 2019

            I’m also seeing this on 2019.1, both -c Debug and Release

  12. kodbuse says:

    October 17, 2019

    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.

    • Maarten Balliauw says:

      October 17, 2019

      Not right now. You could try using the remote debug feature, but note that that needs SSH opened for the container.
      Docker compose support is coming for 2019.3 (EAP should be coming soon)

      • uffe hellum says:

        October 21, 2019



Subscribe to .NET Tools updates