Running and Debugging .NET Apps in Docker Compose from Rider – A Practical Guide

Problem: Local vs Container Development

When a .NET solution grows, developers often move the application into a Docker Compose environment to mirror production. Running the app locally is quick, but debugging inside a container feels like a separate world. The question is: can JetBrains Rider keep the workflow tight and let you debug the same code you edit on the host?

Thesis: Rider’s Docker Compose Support Bridges the Gap

Rider can automatically generate run configurations from a docker-compose.yml, start services via the IDE, and attach a remote debugger to the process inside the container. With volume mounts the code changes live in the container, enabling hot reload. However, the setup is not “plug‑and‑play”; the container image, debugger agent and network settings must line up.

1. Generating and Inspecting the Run Configuration

Open the solution that contains a docker-compose.yml file. Rider parses the file on project load and shows a Docker Compose run configuration in the Run menu.

Run > Edit Configurations…
  + Docker Compose
    Service: web
    Compose file: docker-compose.yml
    Environment: ASPNETCORE_ENVIRONMENT=Development
    Ports: 5000:80
    Volumes:
      - .:/app

Verify that the Service matches the one you want to debug (e.g., web for an ASP.NET Core MVC app). The Ports mapping should expose the container port to the host; Rider will automatically forward the host port to the browser if you enable Open in Browser.

2. Using the Docker Tool Window

Rider’s Docker tool window (View > Tool Windows > Docker) shows images, containers, logs and the compose services. From here you can:

• Start or stop a compose service.
• Tail logs by clicking the Logs tab.
• Inspect environment variables and volume mounts.

Example: click web → Start. In the Logs tab you should see the ASP.NET Core startup banner.

3. Remote Debugging Inside the Container

To hit breakpoints you need the debugger agent in the image. For a standard ASP.NET Core image, Rider injects the dotnet-monitor agent automatically when you use the Docker Compose run configuration. If the image is custom, add the agent manually:

FROM mcr.microsoft.com/dotnet/aspnet:8.0
RUN dotnet tool install --global dotnet-monitor
ENV DOTNET_MONITOR_PORT=5000
ENV DOTNET_MONITOR_HOST=0.0.0.0
EXPOSE 5000
ENTRYPOINT ["dotnet-monitor", "run", "--urls", "http://*:5000"]

After rebuilding the image, restart the compose service. In Rider, choose Run > Attach to Process, select the container process, and the debugger should hit any breakpoint you set in the source file.

4. Hot Reload with Volume Mounts

Mount the project directory into the container (- .:/app) so that changes on the host are reflected inside the container. Rider’s Hot Reload feature will detect file changes and push them to the running process without a rebuild. Note that hot reload works best with the dotnet watch tool in the image or with the built‑in hot reload support in .NET 8.

Verify hot reload by editing a controller action, saving, and seeing the change reflected in the browser without restarting the container.

5. Trade‑offs and Limitations

• Startup Overhead – Launching a compose service and attaching the debugger takes longer than a local run.
• Image Compatibility – The container must run the same .NET runtime version as the host SDK; mismatches break the debugger.
• Windows vs Linux Containers – Windows containers require a Windows Docker host and use different volume syntax; Rider’s auto‑generation may mis‑interpret paths.
• Network Isolation – If the compose file uses an isolated network, Rider’s debugger cannot reach the agent unless you expose the debug port.
• Hot Reload Reliability – Multi‑stage Dockerfiles or complex build contexts can prevent Rider from detecting file changes.

6. Actionable Checklist

1. Confirm the docker-compose.yml defines the service you want to debug.
2. Open the Docker Compose run configuration and verify ports, environment and volume settings.
3. Ensure the image contains the debugger agent (or add it as shown).
4. Start the service from the Docker tool window and watch the logs.
5. Set breakpoints in Rider, then choose Attach to Process and select the container process.
6. Make a code change, save, and confirm hot reload by refreshing the browser.
7. If breakpoints don’t hit, check that the container’s debug port is exposed and that the .NET runtime matches.

By following this workflow you keep the power of Rider’s debugging and code‑navigation tools while running your application in a realistic Docker Compose environment.