Debugging .NET Core Applications in Docker using JetBrains Rider

The Problem: Context Switching During Container Development

Developing .NET Core applications in containers often requires a fragmented workflow: writing code in an IDE, manually running docker build and docker run in a terminal, and then attempting to attach a remote debugger to a running process. This cycle slows down the feedback loop and complicates the debugging process.

The takeaway is that Rider's built-in Docker integration collapses these steps into a single Run/Debug Configuration. Rider handles the image build, container lifecycle, and debugger attachment automatically, allowing you to hit breakpoints in containerized code as if it were running locally.

How the Integration Works

When you execute a Docker .NET Core configuration, Rider orchestrates several background tasks:

• Image Orchestration: It uses the specified Dockerfile to build the image and push it to your local Docker daemon.
• Environment Injection: Rider automatically injects necessary .NET runtime environment variables (such as ASPNETCORE_URLS) and mounts the project folder as a volume so that source changes can be reflected without a full rebuild.
• Debugger Attachment: The IDE deploys the .NET debugger (vsdbg) into the container and establishes a connection, enabling full inspection of variables and call stacks.

This requires the Docker CLI to be available on your host machine's PATH and a running Docker daemon (e.g., Docker Desktop).

Implementation Example

To set this up, you need a valid Dockerfile and a corresponding Rider Run Configuration.

1. Multi-stage Dockerfile

Place this file at your solution root. This example assumes a .NET 8.0 project named MyApi.

# syntax=docker/dockerfile:1
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 8080

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["MyApi/MyApi.csproj", "MyApi/"]
RUN dotnet restore "MyApi/MyApi.csproj"
COPY . .
WORKDIR "/src/MyApi"
RUN dotnet publish -c Release -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApi.dll"]

2. Configuring Rider

1. Navigate to Run > Edit Configurations.
2. Click the + icon and select Docker .NET Core.
3. Dockerfile: Select the path to the file created above.
4. Target Framework: Select net8.0.
5. Port Bindings: Map 8080:8080 (Host:Container) to ensure the IDE can reach the application.
6. Click OK.

3. Multi-Service Setup (Docker Compose)

If your application requires a database, use a docker-compose.yml file. Rider can target a specific service within the compose file for debugging.

version: "3.9"
services:
  api:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    environment:
      - ConnectionStrings__Default=Server=db;Database=MyDb;User=sa;Password=YourStrongPassword123;
    depends_on:
      - db
  db:
    image: mcr.microsoft.com/mssql/server:2022-latest
    environment:
      - ACCEPT_EULA=Y
      - SA_PASSWORD=YourStrongPassword123

In the Run Configuration, choose Docker Compose, point to this file, and select the api service as the debug target.

Limitations and Common Pitfalls

• Daemon Connectivity: If the Docker daemon is not running, Rider will return a "Cannot connect to Docker daemon" error. Ensure Docker Desktop is active.
• Windows File System Performance: On Windows, using the legacy Hyper-V backend can cause file-watching issues where source changes aren't detected. Use the WSL2 backend for optimal compatibility.
• Permission Issues: On Linux, the user running Rider must be part of the docker group to interact with the daemon without sudo.
• Compose Versioning: Using a Docker Compose version older than 3.9 may result in unsupported network or volume options when Rider generates configurations.
• Framework Support: Auto-generated Dockerfiles typically target .NET 6 or later. Older frameworks require manual Dockerfile authoring.

Verification and Rollback

To verify the setup, set a breakpoint in Program.cs and press F5. Check the following:

• The Run window shows Building image... followed by Container started.
• Running docker ps in a terminal confirms the container is active and port 8080 is mapped.
• The debugger pauses execution at the breakpoint, allowing you to inspect local variables.

Rollback: To revert changes, stop the debug session. Rider removes the container by default. To manually clean up, run docker rm -f <container_id> and docker rmi <image_id> via the terminal.