Docker Build Fails at Publish Stage for .NET 9.0 Blazor WASM Stand-Alone PWA

In your publish step, you have the following

DOCKERFILECopied
#Publish portion
FROM build AS publish 
ARG BUILD_CONFIGURATION=Release
WORKDIR ./docker-test/build
RUN dotnet publish -c $BUILD_CONFIGURATION -o ./docker-test/build/publish apphost=false

In there, you change the work directory from what it was during build, so now it can't find the project file.

If you keep the same directory and specify the project file like you do on the build command, you should be able to get past the error.

Another issue is that you use relative paths all the way through the Dockerfile leading to a very deep directory structure at the end. Relative to the starting directory in the build stage, you end up publishing into ./docker-test/docker-test/docker-test/build/docker-test/build/publish which is not what you want. Use absolute paths for the WORKDIRs and maybe relative paths for the output of build and publish.

Regarding what ports your app listens on, you've EXPOSED ports 7149 and 5108. The EXPOSE statement is mainly documentation for the consumer of an image and in your case, I think the ports are wrong. When you run your application from inside VS, it sets the ports so that might be what you see. But when you run an ASP.NET image from outside VS, it'll listen on port 8080 for HTTP traffic by default. So I'd change the EXPOSE to port 8080. But like I said, it's only documentation, so whatever it says doesn't change the behaviour of the container when you run it.

With those changes, you should have something like this

DOCKERFILECopied
# Dev portion
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
EXPOSE 8080

# Restore portion
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
ARG BUILD_CONFIGURATION=Release
WORKDIR /docker-test
COPY . ./
RUN dotnet restore

# Build portion
WORKDIR /docker-test/docker-test
RUN dotnet build ./docker-test.csproj -c $BUILD_CONFIGURATION -o ./build

#Publish portion
FROM build AS publish 
ARG BUILD_CONFIGURATION=Release
# Publish and put output in /docker-test/docker-test/publish
RUN dotnet publish ./docker-test.csproj -c $BUILD_CONFIGURATION -o ./publish apphost=false

# Image build portion
FROM base AS final
WORKDIR /app 
COPY --from=publish /docker-test/docker-test/publish .
ENTRYPOINT ["dotnet", "docker-test.dll"]

Your Dockerfile is not wrong, but the "intention" is.

Containers are used to wrap applications in a standard and lightweight environment. Basically, you can use containers to deliver your application with the environment together. Inside a Dockerfile is expected that you describe steps to "Build" the environment and run your application. See about multi-stage builds

Your Dockerfile is doing more than just building the environment and giving instructions to run your app in that environment, your Dockerfile is doing everything involved in the release of a product, this is normally described in a CI/CD pipeline.

In simple terms, the pipeline will automate all needed stages of your deployment, like "test", "build" and "release".

You cannot do all those stages inside the Dockerfile, but you can split the build stages to not deliver the building environment.

Basically, you need to extract the "Publish Portion" of your dockerfile to a CI/CD pipeline and execute that command after your Dockerfile build is finished. You can try "GitHub Actions" if your code is on github. (But the list of CI/CD tools is huge, you can check Jenkins, GitlabCI, Bitbucket Pipelines, Azure DevOps, AWS Codebuild... )