Dockertools: Running Docker-Compose project in Release Configuration Errors out

Created on 12 Sep 2019  路  14Comments  路  Source: microsoft/DockerTools

When launching a Docker-Compose project in VS2019, and the configuration is set to Release, the a dotnet command being run is generated with --additionalProbingPath parameters, which the dotnet sdk gives this message.
image

The base image being used is mcr.microsoft.com/dotnet/core/sdk:2.2.

Most helpful comment

Seeing this in .NET core 3 in release builds without debugging. Is there a way to turn off that argument?

All 14 comments

Can you share the contents of docker-compose.yml, docker-compose.override.yml, and objDockerdocker-compose.vs.debug.yml?

docker.compose.yml

version: '3.4'

networks:
  default:
    external:
      name: platform

services:
  vc-administration:
    image: ${DOCKER_REGISTRY-}vcadministration
    build:
      context: .
      dockerfile: ../vc-administration/Dockerfile.develop
    environment:
      - DynamoConfig__LocalEndpoint=http://dynamodb:8000
      - ConfigurationServer__uri=http://consul:8500/
      - AWS_SECRET_ACCESS_KEY=AWS_SECRET_ACCESS_KEY
      - AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_ID
      - AWS_ENABLE_ENDPOINT_DISCOVERY=false
      - baseUri={host}/vc/administration
    labels:
      - "traefik.frontend.rule=PathPrefix: /vc/administration;"

docker-compose.override.yml

version: '3.4'

services:
  vc-administration:
#    environment:
#      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "80"
    volumes:
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets:ro

docker-compose.vs.debug.g.yml

version: '3.4'

services:
  vc-administration:
    image: vcadministration:dev
    build:
      target: base
      labels:
        com.microsoft.created-by: "visual-studio"
        com.microsoft.visual-studio.project-name: "vc-administration"
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
      - NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages
    volumes:
      - C:\bitbucket\vc\vc-administration\vc-administration:/app
      - C:\Users\zovin.khanmohammed\vsdbg\vs2017u5:/remote_debugger:ro
      - C:\Users\zovin.khanmohammed\.nuget\packages\:/root/.nuget/packages:ro
      - C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets: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.2/vc-administration.dll\""
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/sh -c \"if PID=$$(pidof dotnet); then kill $$PID; fi\""

@zikhan Strange, your arguments look fine. Can you try pulling the latest Docker base images, if you haven't already? Maybe that will help.

docker pull mcr.microsoft.com/dotnet/core/sdk:2.2
docker pull mcr.microsoft.com/dotnet/core/aspnet:2.2

@sgreenmsft I've never heard of dotnet being case-sensitive about arguments, have you?

I deleted the images and pulled them. Same error. I am running on Linux Containers btw.

@zikhan So it seems you've run into a strange inconsistency between the SDK and runtime images. The SDK image is case-sensitive in that parameter whereas the runtime image is not. You can work around it by creating a docker-compose.vs.debug.yml (for debug mode) and docker-compose.vs.release.yml (for release mode) file, alongside the docker-compose.yml and docker-compose.override.yml, with these contents:

version: '3.4'

services:
  vc-administration:
    labels:
      com.microsoft.visualstudio.debuggee.arguments: " --additionalprobingpath /root/.nuget/packages --additionalprobingpath /root/.nuget/fallbackpackages  \"bin/Debug/netcoreapp2.2/vc-administration.dll\""

This is funny: if the configuration is set to debug, the container runs just fine with the same sdk base image.
I can just switch the Configuration dropdown from Release -> Debug without any other changes to the dockerfile or docker-compose yamls and it'll run just fine. But the other way causes the error.

Any chance the vcadministration:dev image is old? Does Debug configuration stop working if you delete that image?

I just deleted the vcadministration:dev image via image id. Reran the Docker-Compose play button which rebuilt the image and Debug worked.
I then deleted the vcadministration:dev image via image id again. Reran the Docker-Compose play button in Release configuration which rebuilt the image and Release outputted the unknown option message.

@zikhan - Can you provide the contents of objdockerdocker-compose.vs.release.g.yml?

docker-compose.vs.release.g.yml

version: '3.4'

services:
  vc-administration:
    build:
      labels:
        com.microsoft.created-by: "visual-studio"
        com.microsoft.visual-studio.project-name: "vc-administration"
    volumes:
      - C:\Users\zovin.khanmohammed\vsdbg\vs2017u5:/remote_debugger:ro
      - ${APPDATA}/ASP.NET/Https:/root/.aspnet/https:ro
      - ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/usersecrets: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  \"vc-administration.dll\""
      com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
      com.microsoft.visualstudio.debuggee.killprogram: "/bin/sh -c \"if PID=$$(pidof dotnet); then kill $$PID; fi\""

Thanks, @zikhan. Is your dockerfile possibly not copying the dotnet publish output (i.e. vc-administration.dll and associated files) into the /app directory? It turns out that the dotnet SDK will give the above error about additionalProbingPath being an unknown option if it can't find the specified assembly (vc-administration.dll).

nope, I thought the container tools were doing that.

Here's my dockerfile

FROM mcr.microsoft.com/dotnet/core/sdk:2.2 as base
WORKDIR /app
EXPOSE 80
ENV urls "http://*:80"
RUN mkdir /root/.aws/ && touch /root/.aws/credentials

Okay, I just read the docs... https://docs.microsoft.com/en-us/visualstudio/containers/container-build?view=vs-2019#faster-builds-for-the-debug-configuration

Thanks for y'all's help.

Seeing this in .NET core 3 in release builds without debugging. Is there a way to turn off that argument?

Was this page helpful?
0 / 5 - 0 ratings