基于新增Web应用的多项目.NET Core解决方案构建Docker容器

咱们先梳理下原来Dockerfile的核心问题：之前解决方案只有一个Web-API项目，直接执行dotnet publish会默认处理启动项目，但现在多了一个Web应用，直接跑dotnet publish可能会因为多个可发布项目报错，或者输出路径不符合预期。所以核心调整点是明确指定要发布的项目路径，同时优化冗余的构建步骤。

下面分两种常见场景给出具体方案：

场景1：继续构建Web-API项目 #

如果你的目标还是打包原来的Web-API服务，只需要修改dotnet publish命令，明确指定API项目的路径，避免多项目带来的歧义：

# 构建阶段
FROM microsoft/aspnetcore-build:2.0 AS build-env
WORKDIR /app

# 先复制解决方案和各项目的csproj文件，利用Docker缓存加速依赖还原
COPY *.sln ./
COPY Web-API/Web-API.csproj ./Web-API/
COPY Infrastructure/Infrastructure.csproj ./Infrastructure/
COPY Web/Web.csproj ./Web/ # 新增Web项目的csproj，用于还原依赖

RUN dotnet restore

# 复制所有代码文件
COPY . ./

# 明确指定发布Web-API项目，输出到out目录
RUN dotnet publish Web-API/Web-API.csproj -c Release -o out

# 运行时镜像
FROM microsoft/aspnetcore:2.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "API.dll"]

调整说明： #

• 拆分COPY步骤：先复制.sln和各项目的.csproj，这样依赖包的还原可以复用Docker缓存，后续代码变更时无需重新下载依赖，大幅加快构建速度。
• dotnet publish明确指定项目路径，避免多项目环境下的自动选择错误。
• 简化运行时镜像的文件路径，直接将发布后的out目录复制到/app，ENTRYPOINT里直接写dll名称即可，无需完整路径。

场景2：构建新增的Web应用项目 #

如果你的目标是打包新增的Web应用，只需要修改dotnet publish的项目路径和ENTRYPOINT里的dll名称：

# 构建阶段
FROM microsoft/aspnetcore-build:2.0 AS build-env
WORKDIR /app

# 复制解决方案和所有项目的csproj
COPY *.sln ./
COPY Web-API/Web-API.csproj ./Web-API/
COPY Infrastructure/Infrastructure.csproj ./Infrastructure/
COPY Web/Web.csproj ./Web/

RUN dotnet restore

COPY . ./

# 发布新增的Web应用项目
RUN dotnet publish Web/Web.csproj -c Release -o out

# 运行时镜像
FROM microsoft/aspnetcore:2.0
WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "Web.dll"] # 替换为你的Web应用项目实际输出的dll名称

注意点： #

• 请确保ENTRYPOINT里的dll名称和你的Web应用项目名称一致（默认输出dll名称和项目名相同）。
• 不管你的Web应用是Razor Pages、MVC还是Blazor项目，这个发布逻辑都适用。

额外建议： #

如果需要同时部署Web-API和Web应用，更推荐为每个项目单独编写Dockerfile，然后用Docker Compose编排两个容器。这种方式符合服务隔离原则，后续也方便独立扩容、维护和版本管理。

内容的提问来源于stack exchange，提问作者Flatron