web-dev-qa-db-fra.com

Docker: les applications fonctionnent correctement via docker-compos up, mais comment l’exécuter via Visual Studio et le débogage?

J'ai plusieurs projets et ils doivent être exécutés dans des conteneurs séparés, et j'ai une bibliothèque partagée qui devrait également être conçue. J'ai trouvé le article suivant comment le faire. Je montrerai le fichier docker pour un seul projet, car ils sont pratiquement identiques:

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

Donc, comme vous pouvez le voir, on utilise un bâtiment à plusieurs étages. si j'utilise docker-compose up alors tout va bien. Ensuite, j'essaie de l'exécuter via Visual Studio, toutes les étapes sont affichées dans la fenêtre Output, mais le message d'erreur suivant s'affiche:

Le processus cible s'est arrêté sans déclencher un événement lancé par CoreCLR. Assurez-vous que le processus cible est configuré pour utiliser .NET Core. Cela peut être attendu si le processus cible ne s'est pas exécuté sur .NET Core. Le programme '[13] dotnet' s'est terminé avec le code 145 (0x91). Le programme '' s'est terminé avec le code 145 (0x91).

Mais comment déboguer l'application maintenant? C'est le lien vers github repo .

PS Pour Tarun, fichier fixe par défaut généré par le VS

FROM Microsoft/aspnetcore:2.0
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", "Web.dll"]
c#visual-studiodockerasp.net-coredocker-compose
7
user348173

TL; DR;

J'ai donc installé VS 2017 et eu un Dig à cela pour comprendre ce qui se passe ici. Après avoir examiné le processus de construction de votre projet, j'ai trouvé ci-dessous

docker-compose -f "C:\Utilisateurs\tarlabs\Bureau\AspNetCoreMultiProject\docker-composition.yml" -f "C:\Utilisateurs\tarlabs\Bureau\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"

Ce qui n'est pas très intéressant. 

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

Peu de choses intéressantes

  • La ENTRYPOINT que nous définissons ne fera aucune différence pendant le débogage car elle est remplacée par le VS avec tail -f /dev/null
  • Le com.Microsoft.visualstudio.debuggee.arguments a une valeur avec le chemin bin/Debug/netcoreapp2.0/Web.dll
  • Le répertoire de travail pour le débogage est toujours défini sur /app à l'aide de com.Microsoft.visualstudio.debuggee.workingdirectory
  • Montage en volume C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app

En regardant Volume mount C:\Users\tarlabs\Desktop\AspNetCoreMultiProject:/app, j'étais comme Wow! Tout ce que vous avez dans votre dossier /app dans votre fichier Docker sera simplement remplacé par ce montage. Donc, si vous construisez et mettez les fichiers à l'intérieur ou si vous ne faites rien, cela ne fera aucune différence.

Maintenant, je suis entré dans le conteneur et je me suis rendu compte que le Web.dll est un initié /app/Web/bin/Debug/netcoreapp2.0/Web.dll mais que le débogueur s'attend à ce qu'il soit sur /app/bin/Debug/netcoreapp2.0/Web.dll. Après avoir cherché dans tous les contextes, je ne pouvais trouver ce chemin nulle part 

Ensuite, j'ai joué avec un nouveau projet. Ajout d'un projet avec le support Docker et ajout ultérieur d'un autre projet avec le support Docker. Cela m'a donné un indice que le docker-compose.yml était

version: '3'

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

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

Cela m'a laissé entendre que le fichier docker-compose.vs.debug.g.yml dynamique prend le montage de volume en fonction du contexte donné dans votre docker-compose.yml. Regardons maintenant votre projet.

docker-compose.yml 

version: '3'

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

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

Puisque le contexte est ., le montage en volume est généré comme suit: 

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

Pour corriger cela, nous mettons à jour notre docker-compose.yml en 

version: '3'

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

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

Ensuite, notre fichier Dockerfile faisait trop de choses que le débogueur VS ignore en quelque sorte. Donc, vous avez juste besoin de 2 lignes dans votre Dockerfile pour que le débogage fonctionne réellement

FROM Microsoft/aspnetcore:2.0 AS base
WORKDIR /app

Reste que tout ce que vous avez fait a été jeté par le support de volume. Donc, inutile de faire cela pour le débogage. Vous pouvez utiliser une approche de construction en plusieurs étapes pour le déploiement en production, mais pas pour le débogage. Après avoir effectué ces deux modifications dans votre projet, le débogage a commencé à fonctionner pour moi

 Debugging Working

19
Tarun Lalwani

J'ai eu exactement le même problème lors de la création de .Net 2.0 App pour Linux. J'ai essayé toutes les étapes ci-dessus et cela n'a pas aidé. Le problème pour moi était que j'avais utilisé des espaces dans les noms de fichiers csproj et les répertoires de projets.

Lorsque j'ai supprimé les espaces, le problème a été résolu. J'ai essayé de créer une application .Net Core appelée "WebApplication 1" et elle a également échoué. Cela ressemble donc à un bogue dans l'outil VS ou dans le fichier docker/les fichiers composés qu'il crée.

0
GraemeMiller

Avait le même problème en raison d'un symbole Sharp (#) dans mon chemin de projet (comme en C # ... comme C:\Project\C#\MyProject\). 

Suppression du symbole pointu du chemin (C:\Project\C-sharp\MyProject\) et j'étais prêt à partir. 

0
Max R.