Not found application or .NET SDKs issue when running docker-compose

[noh626]

Hi,

I'm attempting to integrate Docker support into my solution, but I'm facing issues when using docker-compose.

To diagnose the problem, I created a test ASP project within my existing solution, Then, I added Docker support and orchestrator to this test project.

When I run the project using Docker directly from Visual Studio, everything works fine.

However, the problem arises when I try to run the docker-compose project. Docker returns the below error. Interestingly, when I replicate the same project structure in a brand new solution, everything works fine with docker-compose.

As part of troubleshooting, I modified the entry point to target an ".exe". But docker continues to search for a ".dll".

Is this issue related to adding a specific prefix to output binaries? I've configured my project to prepend a "MyProject" prefix to the output binaries, leading to filenames like "MyProject.WeatherForecast.dll" or "MyProject.WeatherForecast.exe".
=> I don't think this is the culprit. I just tried a new solution with the prefix. It still works.

| The command could not be loaded, possibly because:
|   * You intended to execute a .NET application:
|       The application 'C:\app\MyProject.WeatherForecast.dll' does not exist.
|   * You intended to execute a .NET SDK command:
|       No .NET SDKs were found.

This is the log from Container Tools.

name: dockercompose17263995661961093974
services:
  WeatherForecast:
    build:
      context: C:\Users\user\Source\Repos\MyProject
      dockerfile: src\WeatherForecast\Dockerfile
      args:
        BUILD_CONFIGURATION: Release
      labels:
        com.microsoft.created-by: visual-studio
        com.microsoft.visual-studio.project-name: WeatherForecast
    container_name: WeatherForecast
    entrypoint:
    - C:\remote_debugger\x64\msvsmon.exe
    - /noauth
    - /anyuser
    - /silent
    - /nostatus
    - /noclrwarn
    - /nosecuritywarn
    - /nofirewallwarn
    - /nowowwarn
    - /fallbackloadremotemanagedpdbs
    - /timeout:2147483646
    - /LogDebuggeeOutputToStdOut
    environment:
      ASPNETCORE_ENVIRONMENT: Development
      ASPNETCORE_URLS: https://+:443;http://+:80
    image: WeatherForecast
    labels:
      com.microsoft.visual-studio.project-name: WeatherForecast
      com.microsoft.visualstudio.debuggee.arguments: ' --additionalProbingPath c:\.nuget\packages  "C:\app\MyProject.WeatherForecast.dll"'
      com.microsoft.visualstudio.debuggee.killprogram: C:\remote_debugger\x64\utils\KillProcess.exe
        dotnet.exe
      com.microsoft.visualstudio.debuggee.program: '"C:\Program Files\dotnet\dotnet.exe"'
      com.microsoft.visualstudio.debuggee.workingdirectory: C:\app
    networks:
      default: null
    ports:
    - mode: ingress
      target: 80
      protocol: tcp
    - mode: ingress
      target: 443
      protocol: tcp
    volumes:
    - type: bind
      source: C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\HotReload
      target: C:\HotReloadAgent
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Sdks\Microsoft.Docker.Sdk\tools\HotReloadProxy\win10-x64\net6.0
      target: C:\HotReloadProxy
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Sdks\Microsoft.Docker.Sdk\tools\TokenService.Proxy\win10-x64\net6.0
      target: C:\TokenService.Proxy
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: C:\Users\user\AppData\Roaming/ASP.NET/Https
      target: C:\Users\ContainerUser\AppData\Roaming\ASP.NET\Https
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: C:\Users\user\AppData\Roaming/Microsoft/UserSecrets
      target: C:\Users\ContainerUser\AppData\Roaming\Microsoft\UserSecrets
      read_only: true
      bind:
        create_host_path: true
    - type: bind
      source: C:\Users\user\onecoremsvsmon\17.8.10726.3412
      target: C:\remote_debugger
      read_only: true
      bind:
        create_host_path: true
networks:
  default:
    name: dockercompose17263995661961093974_default
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/WeatherForecast$" --format {{.ID}} -n 1
7c3fef24e106
docker inspect --format="{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}" 7c3fef24e106
192.168.36.184 
docker exec -i 7c3fef24e106 C:\remote_debugger\x64\utils\KillProcess.exe dotnet.exe
Error response from daemon: Container 7c3fef24e10624578368a28d02660df30665a6174cf2f1c74a49a3243b0146a6 is not running
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/WeatherForecast$" --format {{.ID}} -n 1
7c3fef24e106
docker inspect --format="{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}" 7c3fef24e106
192.168.41.37 
docker exec -i 7c3fef24e106 C:\remote_debugger\x64\utils\KillProcess.exe dotnet.exe
Error response from daemon: No such container: 7c3fef24e106
========== Debugging ==========
docker ps --filter "status=running" --filter "label=com.docker.compose.service" --filter "name=^/WeatherForecast$" --format {{.ID}} -n 1
809b30d83140
docker inspect --format="{{range .NetworkSettings.Networks}}{{.IPAddress}} {{end}}" 809b30d83140
172.25.161.52 

Dockerfile

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
ARG BUILD_CONFIGURATION=Debug
WORKDIR /src
COPY ["Directory.Build.props", "."]
COPY ["Directory.Build.targets", "."]
COPY ["NuGet.config", "."]
COPY ["src/WeatherForecast/WeatherForecast.csproj", "src/WeatherForecast/"]
RUN dotnet restore "src/WeatherForecast/WeatherForecast.csproj"
COPY . .
WORKDIR "/src/src/WeatherForecast"
RUN dotnet build "WeatherForecast.csproj" -c $BUILD_CONFIGURATION -o /app/build

FROM build AS publish
RUN dotnet publish "WeatherForecast.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["WeatherForecast.exe"]

Docker-compose.yml

version: '3.4'
services:
  WeatherForecast:
    image: ${DOCKER_REGISTRY-}WeatherForecast
    build:
      context: .
      dockerfile: src\WeatherForecast\Dockerfile

My project structure

- Solution
    - src
        - WeatherForecast
            - Dockerfile
            - WeatherForecast.csproj 
    - docker-compose.yml

[patverb]

So I think you are on the right path on what the issue could be. When using compose in visual studio, we override the entry point with launching your application via the debugger. If you look at the label com.microsoft.visualstudio.debuggee.arguments: at the very end we tell the debugger to launch C:\app\MyProject.WeatherForecast.dll.

In the container, is the dll called WeatherForecast.dll and not MyProject.WeatherForecast.dll? If so I'm curious how you prefix the MyProject. because we calculate that based on the value of the msbuild parameter $(TargetPath). If I can get a way to make a repro project I can try to figure out why its different.

A work around for now if you are on the latest VS, you can right click on your compose project -> Add -> VS Compose Override Files. This will create 2 files (one each for debug/release) that overrides those values. Un comment the services, service name, labels and the com.microsoft.visualstudio.debuggee line. On that line replace $debuggee_arguments_probing_paths_MyProject.WeatherForecast$ with --additionalProbingPath c:\.nuget\packages and C:\app\MyProject.WeatherForecast.dll with C:\app\<dll file name>.dll replacing <dll file name> with whatever the name of the final dll is.