Attaching to a docker container is quite similar to attaching to a process, the different part is that you need to select the corresponding connection type and connection target.
You may encounter the following issues when debugging with the attached docker container.
1.Unable to find debugger script at ‘/root/.vs-debugger’
This is usually because thevs-debugger is not installed, and can be resolved with the following commands.
docker exec -u root sh -c "apt-get update && apt-get install wget -y"docker exec sh -c "mkdir -p ~/.vs-debugger; wget https://aka.ms/getvsdbgsh -O ~/.vs-debugger/GetVsDbg.sh; chmod a+x ~/.vs-debugger/GetVsDbg.sh"
2. ‘The breakpoint will not currently be hit’ warning
Check the docker file, the image is built and published to ‘Release’ by default, it needs to be ‘Debug’ for debugging purposes, which is the most common mistake. You could also introduce a build/publish mode ARG, and make it configurable, for example
In the docker file define ARG ‘Mode’
.......ARG Mode=DebugRUN echo "$Mode"COPY ["xxx.csproj", "xxx/"]RUN dotnet restore "xxx.csproj"COPY . .WORKDIR "/src/xxx"RUN dotnet build "xxx.csproj" -c $Mode -o /app/buildFROM build AS publishRUN dotnet publish "xxx.csproj" -c $Mode -o /app/publish /p:UseAppHost=false.........
Then in the docker-compose file, assign the Mode with Debug or Release.
services: app: image: xxx:latest build: context: . dockerfile: Dockerfile args: - Mode=Debug
3. Breakpoints look all right but can be hit anyway.
This is usually more complicated, but there are a few checkpoints you could start with.
a. Check the Debug->Windows->Mudules, and make sure the required symbols are loaded. Sometimes the list is empty, no worry, it’s loading, and the breakpoint will work when it’s all loaded.
b. Setfull to avoid code optimization.