Docker: applications works fine via docker-compose

Question

I have several projects and they must be running in seperate containers, and I have some shared library that should be buit also. I have found the following article how to do it. I will show the docker file for one project only, because they are pretty the same:

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0 AS builder
WORKDIR /src
COPY *.sln ./
COPY Web/Web.csproj Web/
RUN dotnet restore
COPY . .
WORKDIR /src/Web
RUN dotnet build -c Debug -o /app

FROM builder AS publish
RUN dotnet publish -c Debug -o /app

FROM base AS production
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "Web.dll"]

So, as you can see multi-stage building is used. if I use docker-compose up then all works fine. Next, I am trying to run it via Visual Studio, I see all steps in Output window, but in the end I get the following error:

The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program '[13] dotnet' has exited with code 145 (0x91). The program '' has exited with code 145 (0x91).

But how to debug the application now? This is the link to github repo.

PS. For Tarun, default docker file that VS generates

FROM microsoft/aspnetcore:2.0
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "Web.dll"]

Answer 1

TL;DR;

So I installed VS 2017 and had a dig at this to understand what goes on here. After looking at the build process for your project I found below

docker-compose -f "C:\Users\tarlabs\Desktop\AspNetCoreMultiProject\docker-compose.yml" -f "C:\Users\tarlabs\Desktop\AspNetCoreMultiProject\docker-compose.override.yml" -f "C:\Users\tarlabs\Desktop\AspNetCoreMultiProject\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose15184637154516733497 kill

docker-compose.override.yml

version: '3'

services:
  web:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "80"

  api:
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "80"

Which is not much of interest.

docker-compose.vs.debug.g.yml

version: '3'

services:
  api:
    image: api:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages
    volumes:
      - C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app
      - C:\Users\tarlabs\vsdbg:/remote_debugger:ro
      - C:\Users\tarlabs\.nuget\packages\:/root/.nuget/packages:ro
      - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro

    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages  bin/Debug/netcoreapp2.0/Api.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

  web:
    image: web:dev
    build:
      args:
        source: obj/Docker/empty/
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages
    volumes:
      - C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app
      - C:\Users\tarlabs\vsdbg:/remote_debugger:ro
      - C:\Users\tarlabs\.nuget\packages\:/root/.nuget/packages:ro
      - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro

    entrypoint: tail -f /dev/null
    labels:
      com.microsoft.visualstudio.debuggee.program: "dotnet"
      com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages  bin/Debug/netcoreapp2.0/Web.dll"
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/bash -c \"if PID=$$(pidof -x dotnet); then kill $$PID; fi\""

Few interesting things

• The ENTRYPOINT we define won't make a difference during debugging as it overridden by VS with tail -f /dev/null
• The com.microsoft.visualstudio.debuggee.arguments has a value with path bin/Debug/netcoreapp2.0/Web.dll
• The working directory for debugging is always set to /app using com.microsoft.visualstudio.debuggee.workingdirectory
• Volume mount C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app

Looking at Volume mount C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app, I was like Wow! Anything that you have in your /app folder in your Dockerfile, will be just overridden by that mount. So whether you build and put the files inside that or you don't do anything won't make a difference.

Now I went inside the container and realized that the Web.dll is insider /app/Web/bin/Debug/netcoreapp2.0/Web.dll but the debugger is expecting it to be on /app/bin/Debug/netcoreapp2.0/Web.dll. After looking in every setting I could not find this path anywhere.

Then I played around with a new project. Adding one project with Docker support and later adding another project with docker support. This gave me a hint as the docker-compose.yml was

version: '3'

services:
  webapplication1:
    image: webapplication1
    build:
      context: ./WebApplication1
      dockerfile:Dockerfile

  webapplication2:
    image: webapplication2
    build:
      context: ./../WebApplication2
      dockerfile: Dockerfile

This gave me a hint that the dynamic docker-compose.vs.debug.g.yml file takes the volume mount based on the context given in your docker-compose.yml. Now looking at your project.

docker-compose.yml

version: '3'

services:
  web:
    image: web
    build:
      context: .
      dockerfile: Web/Dockerfile

  api:
    image:api
    build:
      context: .
      dockerfile: Api/Dockerfile

Since the context is . the Volume mount is generated as

- C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app

To correct that we update our docker-compose.yml to

version: '3'

services:
  web:
    image: web
    build:
      context: ./Web
      dockerfile: Dockerfile

  api:
    image:api
    build:
      context: ./Api
      dockerfile: Dockerfile

Next our Dockerfile was doing too many things which VS debugger kind of just ignores. So you just needs 2 lines in your Dockerfile for debugging to actually work

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app

Rest anything that you did was just thrown away by the volume mount. So no point in doing that for debugging. You can use multistage build approach for deploying to production but not for debugging. After making those two changes in your project debugging started working for me

Answer 2

Had the same issue because of a Sharp Symbol (#) in my project path (Like in C#... like C:\Project\C#\MyProject\).

Removed the sharp symbol from the path (C:\Project\C-sharp\MyProject\) and I was good to go.

Answer 3

I had the exact same issue building .Net 2.0 App for Linux. Tried all the steps above and it didn't help. The issue for me was that I had used spaces in csproj file names and project directories.

When I removed the spaces it fixed the issue. I tried creating a .Net Core Application called "WebApplication 1" and it also failed so seems like a bug in VS tooling or the docker file/compose files it creates.