Docker: Anwendungen funktioniert gut über Docker-komponieren, aber wie man es über Visual Studio und Debuggen?

Question

Ich habe mehrere Projekte und sie müssen in getrennten Containern laufen, und ich habe einige gemeinsame Bibliothek, die auch gebaut werden sollte. Ich habe folgendes gefunden article wie es geht. Ich werde nur die Docker-Datei für ein Projekt zeigen, da sie ziemlich gleich ist:

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, wie Sie mehrstufigen Gebäude verwendet werden, sehen. Wenn ich docker-compose up verwende, dann funktioniert alles gut. Als nächstes versuche ich es über Visual Studio zu laufen, sehe ich alle Schritte in Output Fenster, aber am Ende habe ich die folgende Fehlermeldung erhalten:

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).

Aber wie nun die Anwendung debuggen? Dies ist der Link zu github repo.

PS. Für Tarun, default Andockfensters Datei, die VS erzeugt

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

Answer 1

TL; DR;

Also ich installiert VS 2017 und hatte eine Ausgrabung, um zu verstehen, was hier passiert. Nach der Suche nach Ihrem Projekt in dem Build-Prozess fand ich unter

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" 

die nicht viel von Interesse ist.

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\"" 

Ein paar interessante Dinge

• Die ENTRYPOINT definieren wir keinen Unterschied bei der Fehlersuche machen, wie es von VS außer Kraft gesetzt mit tail -f /dev/null
• Die com.microsoft.visualstudio.debuggee.arguments hat einen Wert mit Pfad bin/Debug/netcoreapp2.0/Web.dll
• Das Arbeitsverzeichnis für das Debuggen ist immer auf /appcom.microsoft.visualstudio.debuggee.workingdirectory mit
• Volume C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app montiert

bei Volume Blick C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app montieren, ich war wie Wow! Alles, was Sie in Ihrem Ordner /app in Ihrer Dockerfile haben, wird nur von diesem Mount überschrieben. Also, ob Sie die Dateien erstellen und dort hineinlegen oder nichts tun, wird keinen Unterschied machen.

Jetzt ging ich in den Container und erkannte, dass die Web.dll ist Insider /app/Web/bin/Debug/netcoreapp2.0/Web.dll, aber der Debugger erwartet, dass es auf /app/bin/Debug/netcoreapp2.0/Web.dll sein wird. Nachdem ich in jeder Umgebung gesucht habe, konnte ich diesen Pfad nirgends finden.

Dann spielte ich mit einem neuen Projekt herum. Hinzufügen eines Projekts mit Docker-Unterstützung und später Hinzufügen eines weiteren Projekts mit Docker-Unterstützung.Dies gab mir einen Hinweis der docker-compose.yml

war

version: '3' 

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

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

Dies gab mir einen Hinweis, dass die dynamische docker-compose.vs.debug.g.yml Datei die Lautstärke nimmt den Kontext in Ihrem docker-compose.yml gegebenen Halterung basiert. Sehen Sie sich jetzt Ihr Projekt an.

Docker-compose.yml

version: '3' 

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

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

Da der Kontext . die Lautstärke ist Halterung als

erzeugt wird

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

zu korrigieren, dass wir unsere docker-compose.yml zu

version: '3' 

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

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

aktualisieren

Weiter unser Docke rfile hat zu viele Dinge gemacht, die VS Debugger einfach ignoriert. So braucht man nur zwei Zeilen in Ihrer Dockerfile für das Debuggen tatsächlich

FROM microsoft/aspnetcore:2.0 AS base 
WORKDIR /app 

Ruhe etwas zu arbeiten, die Sie gerade weg montieren durch das Volumen geworfen tat wurde. Also keinen Grund zum Debuggen. Sie können den mehrstufigen Build-Ansatz für die Bereitstellung in der Produktion, jedoch nicht für das Debugging verwenden. Nachdem für mich, diese beiden Änderungen in Ihrem Projekt Debuggen

Answer 2

hatte ich genau das gleiche Problem Gebäude .Net 2.0 App für Linux zu arbeiten begann. Habe alle obigen Schritte versucht und es hat nicht geholfen. Das Problem für mich war, dass ich Leerzeichen in csproj Dateinamen und Projektverzeichnisse verwendet hatte.

Als ich die Leerzeichen löschte, behob das Problem. Ich habe versucht, eine .Net Core Application namens "WebApplication 1" zu erstellen und es ist auch fehlgeschlagen, so scheint es wie ein Fehler in VS Tooling oder die Docker-Datei/komponieren Sie die Dateien erstellt.