The application 'Clinic.Api.dll' does not exist or is not a managed .dll or .exe. when a .NET container starts means the ENTRYPOINT names a DLL that is not in the image's working folder. List the folder, copy the real file name into the Dockerfile and rebuild.

Listing /app in the image showed ClinicApi.dll next to ClinicApi.csproj's other outputs. In the reproduction the Dockerfile said Clinic.Api.dll; changing it to ClinicApi.dll fixed the start.

The error

PS> docker run --rm --name fix10-dn-dll fix10-dn-wrongdll
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'Clinic.Api.dll' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

Download a .NET SDK:
https://aka.ms/dotnet/download

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

The container exited with code 155.

Why it happens

The last line of the Dockerfile was ENTRYPOINT ["dotnet", "Clinic.Api.dll"]. With no file of that name in /app, the dotnet host printed both of its guesses: an application that does not exist, or an SDK command. The second guess is a red herring here. The runtime image has no SDK, so "No .NET SDKs were found" is printed too, and it is easy to go looking for an SDK problem that is not there.

Listing the folder of the same image shows what was really published: 

PS> docker run --rm --name fix10-dn-dll2 --entrypoint ls fix10-dn-wrongdll /app
ClinicApi
ClinicApi.deps.json
ClinicApi.dll
ClinicApi.pdb
ClinicApi.runtimeconfig.json

The message quotes the name exactly as the Dockerfile wrote it, so compare it letter by letter with this list: Clinic.Api.dll in the error against ClinicApi.dll on disk. The name differs by one dot. Whatever produced the wrong name in your Dockerfile, the ls above shows the name to use.

The fix

FROM mcr.microsoft.com/dotnet/runtime:10.0
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["dotnet", "ClinicApi.dll"]
PS> docker run --rm --name fix10-dn-dll3 fix10-dn-dllfix
ClinicApi started on .NET 10.0.13

The only change between the two Dockerfiles is the file name in the last line. Both images built; the wrong name showed up only when the container started. So a green docker build says nothing about the entry point: start the container once after any change to the last line of the Dockerfile.

How it was reproduced

A console app from dotnet new console -n ClinicApi, no packages, published in a multi-stage Dockerfile on mcr.microsoft.com/dotnet/sdk:10.0 (SDK 10.0.302) and copied onto mcr.microsoft.com/dotnet/runtime:10.0 (Microsoft.NETCore.App 10.0.13), with the ENTRYPOINT changed to Clinic.Api.dll. Docker engine 29.9.3 on Windows 11.

Frequently asked

How do I find the DLL name for a .NET Docker ENTRYPOINT?
Run the image with --entrypoint ls and the folder, for example docker run --rm --entrypoint ls your-image /app. The published dll is listed there; put that exact name in the ENTRYPOINT.
Why does dotnet say No .NET SDKs were found when I run my app in Docker?
When the DLL named in the command was missing, the dotnet host printed two possibilities, a missing application and an SDK command, and the runtime image has no SDK. Fix the DLL name and the SDK line goes away.
Does the docker build fail when the ENTRYPOINT names the wrong DLL?
No. In the test the image built and the error appeared only when the container started, with exit code 155.

The same "No .NET SDKs were found" text for a real SDK command is covered in No .NET SDKs were found in the aspnet or runtime image. More decoded errors in the Fixes category.