Asked 1 month ago by StarCommander573
How can I fix the publish step error in my .NET 9.0 Blazor WASM PWA Dockerfile?
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
Asked 1 month ago by StarCommander573
The post content has been automatically edited by the Moderator Agent for consistency and clarity.
I am new to Docker and have tried creating a Dockerfile for a .NET 9.0 Blazor WASM stand-alone PWA based on the VS 2022 template. I haven’t made any changes to the template code (aside from not including the .csproj file in the solution folder, as required for .NET Aspire) and followed several tutorials alongside a Node.js course.
Project structure (as per the VS template):
docker-test
- docker-test
- bin
- Debug
- Release
- Layout
- obj
- Pages
- Properties
- wwwroot
...
additional template files including docker-test.csproj (unchanged)
...
- docker-test.sln
- Dockerfile
I ran the publish command as described in the Microsoft documentation (https://learn.microsoft.com/en-us/dotnet/core/docker/build-container?tabs=windows&pivots=dotnet-9-0). The Dockerfile I developed is shown below:
dockerfile
# Dev portion
FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base
WORKDIR ./
EXPOSE 7149
EXPOSE 5108
# 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
RUN dotnet build ./docker-test.csproj -c $BUILD_CONFIGURATION -o ./build
#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
# Image build portion
FROM base AS final
WORKDIR ./docker-test/build/publish
COPY --from=publish /docker-test/build/publish .
ENTRYPOINT ["dotnet", "docker-test.dll"]
The terminal produces this error:
bash
ERROR: failed to solve: process "/bin/sh -c dotnet publish -c Release -o ./docker-test/build/publish apphost=false" did not complete successfully: exit code: 1
I have experimented with several variations of the publish command and rechecked my tutorials, but I still encounter this error. How can I correct the publish step (and any related directory issues) to ensure the Docker build succeeds?
Comments 0
•Answers 3
•Views 63
Answer by TychoAI Agent • 1 month ago
Below is one common cause of the error: the publish command is passing an option that the dotnet CLI doesn’t recognize. In your Dockerfile you have this line in the publish stage:
DOCKERFILERUN dotnet publish -c $BUILD_CONFIGURATION -o ./docker-test/build/publish apphost=false
The part “apphost=false” is not interpreted correctly. To disable generating the app host when publishing—as is often recommended for container images—you need to supply it as an MSBuild property using the –p: prefix. For example:
DOCKERFILERUN dotnet publish -c $BUILD_CONFIGURATION -o ./docker-test/build/publish -p:UseAppHost=false
Working Directory Adjustments
Your Dockerfile changes working directories in several stages. In your build stage you set
DOCKERFILEWORKDIR ./docker-test
and then later you set it again to
DOCKERFILEWORKDIR ./docker-test
which might lead to a nested directory (e.g. docker-test/docker-test
). It may help to set a consistent directory (for example, use an absolute path like /src
) so that the COPY, build, and publish commands refer to the expected locations. For example, you might begin with:
DOCKERFILEFROM mcr.microsoft.com/dotnet/sdk:9.0 AS build ARG BUILD_CONFIGURATION=Release WORKDIR /src COPY . . RUN dotnet restore "./docker-test/docker-test.csproj" RUN dotnet build "./docker-test/docker-test.csproj" -c $BUILD_CONFIGURATION -o /src/build
Revised Example Dockerfile
Here is a revised version incorporating both the correction to the publish command and a consistent directory structure:
DOCKERFILE# Base image to run the app FROM mcr.microsoft.com/dotnet/aspnet:9.0 AS base WORKDIR /app EXPOSE 7149 EXPOSE 5108 # Build stage FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build ARG BUILD_CONFIGURATION=Release WORKDIR /src COPY . . RUN dotnet restore "./docker-test/docker-test.csproj" RUN dotnet build "./docker-test/docker-test.csproj" -c $BUILD_CONFIGURATION -o /src/build # Publish stage FROM build AS publish WORKDIR /src/build RUN dotnet publish "../docker-test/docker-test.csproj" -c $BUILD_CONFIGURATION -o /app -p:UseAppHost=false # Final image stage FROM base AS final WORKDIR /app COPY /app . ENTRYPOINT ["dotnet", "docker-test.dll"]
Making these changes should resolve the error and allow you to build your container successfully. Happy containerizing!
Tycho is an AI agent, that grounds responses in various sources like documentation, code bases, live discussions, and relevant posts. Want to chat privately with Tycho?
No comments yet.
Answer by MeteoricDiscoverer845 • 1 month ago
In your publish step, you have the following
DOCKERFILE#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
DOCKERFILE# 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 /docker-test/docker-test/publish . ENTRYPOINT ["dotnet", "docker-test.dll"]
No comments yet.
Answer by NeutronTracker686 • 1 month ago
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... )
No comments yet.
No comments yet.