Docker Could not execute because the application was not found or a compatible .NET SDK is not installed

Viewed 2340

I'm attempting to deploy a .NET 5 console app background service to run in a Docker Linux container on a Linux Azure VM. The final result is that the container exits immediately and log shows:

Could not execute because the application was not found or a compatible .NET SDK is not installed. Possible reasons for this include: * You intended to execute a .NET program: The application 'FileProcessSvcPOC.dll' does not exist. * You intended to execute a .NET SDK command: It was not possible to find any installed .NET SDKs.

The process I've followed is to use docker compose with a remote context to the VM. I've also tried pushing the container to an Azure repository and deployed that way (without compose) and get the same error.

Docker build output (which shows no errors):

=> [internal] load build definition from Dockerfile
0.2s => => transferring dockerfile: 778B 0.1s => [internal] load .dockerignore 0.1s => => transferring context: 35B 0.1s => [internal] load metadata for mcr.microsoft.com/dotnet/sdk:5.0 0.1s => [internal] load metadata for mcr.microsoft.com/dotnet/runtime:5.0
0.2s => [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:5.0@sha256:081a6c31153f16c02eeb7f1ad663adb8e1d21fa0d59402348c13bba7659a5419 0.0s => [base 1/2] FROM mcr.microsoft.com/dotnet/runtime:5.0@sha256:d78f83397086556adecb7d5b9e86751b9b591ffc7c17addaa55109b733cd0f50 0.0s => [internal] load build context 0.1s => => transferring context: 863B 0.1s => CACHED [base 2/2] WORKDIR /app 0.0s => CACHED [final 1/2] WORKDIR /app 0.0s => CACHED [build 2/7] WORKDIR /src 0.0s => CACHED [build 3/7] COPY [FileProcessSvcPOC/FileProcessSvcPOC.csproj, FileProcessSvcPOC/]
0.0s => CACHED [build 4/7] RUN dotnet restore "FileProcessSvcPOC/FileProcessSvcPOC.csproj"
0.0s => CACHED [build 5/7] COPY . . 0.0s => CACHED [build 6/7] WORKDIR /src/FileProcessSvcPOC 0.0s => CACHED [build 7/7] RUN dotnet build "FileProcessSvcPOC.csproj" -c Release -o /app/build
0.0s => CACHED [publish 1/1] RUN dotnet publish "FileProcessSvcPOC.csproj" -c Release -o /app/publish
0.0s => CACHED [final 2/2] COPY --from=publish /app/publish . 0.0s => exporting to image 0.1s => => exporting layers 0.0s => => writing image sha256:04297f1fb6c30fefb6e39005404b868bb8fd740a30de2174ea42780e16120ca7 0.0s => => naming to docker.io/library/fileprocesssvcpoc

Dockerfile:

FROM mcr.microsoft.com/dotnet/runtime:5.0 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /src
COPY ["FileProcessSvcPOC/FileProcessSvcPOC.csproj", "FileProcessSvcPOC/"]
RUN dotnet restore "FileProcessSvcPOC/FileProcessSvcPOC.csproj"
COPY . .
WORKDIR "/src/FileProcessSvcPOC"
RUN dotnet build "FileProcessSvcPOC.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "FileProcessSvcPOC.csproj" -c Release -o /app/publish

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

docker-compose.yml:

version: '3.4'

services:
  fileprocesssvcpoc:
    image: ${DOCKER_REGISTRY-}fileprocesssvcpoc
    build:
      context: .
      dockerfile: FileProcessSvcPOC/Dockerfile

Console app Program.cs CreateHostBuilder

    public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
        .UseSystemd()
                .ConfigureServices((hostContext, services) =>
                {
                    services.AddHostedService<FileListenerSvc>();
                    services.Configure<AppSettings>(hostContext.Configuration.GetSection("AppSettings"));
                });

*Article I read on deploying .NET background service on Linux said to use UseSystemd().

I've deployed a .NET 5 web application to the same Linux VM using Docker context / compose and it runs fine.

Any idea why the set up above for the console app exits with error that suggests .NET SDK is not installed when it is referenced in DockerFile and shows in build output?

1 Answers

The command provided by Matt Thalman in comment to my question showed that the app was being published to the container as a .exe with no dll.

Changing the publish options to produce a dll solved the problem.

Related