使用Dockerfile构建.NET7镜像失败：dotnet build退出码1

以下是针对dotnet build命令执行失败的常见排查方向：

1. 先排除项目本身的编译问题 #

在本地项目根目录执行dotnet build WebApplication1.csproj -c Release，如果本地编译就失败，那问题出在项目代码本身——比如语法错误、引用缺失、目标框架版本不匹配等，先解决本地编译问题再尝试Docker构建。

2. 检查Docker基础镜像是否正确 #

确保构建阶段使用的是**.NET7 SDK镜像**，而非runtime镜像。runtime镜像仅包含运行时环境，没有编译工具，正确示例：

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build

若使用mcr.microsoft.com/dotnet/runtime:7.0或更低版本的SDK镜像，必然会导致构建失败。

3. 确认项目文件路径与Dockerfile指令匹配 #

Docker构建上下文是执行docker build命令的文件夹，需保证：

• COPY指令路径和实际文件位置一致。比如WebApplication1.csproj在构建上下文根目录时，COPY WebApplication1.csproj .是正确的；若项目在子文件夹./src下，需改为COPY ./src/WebApplication1.csproj ./src/，同时调整WORKDIR到对应路径。
• dotnet build命令中的项目路径要和WORKDIR下的文件位置对应。比如WORKDIR设为/src，则/src目录下必须存在WebApplication1.csproj文件。

4. 查看详细构建日志定位具体错误 #

默认Docker构建日志会隐藏dotnet build的具体输出，执行以下命令获取完整日志：

docker build . --progress=plain

日志会显示dotnet build的具体报错信息（如NuGet包下载失败、文件找不到、代码编译错误等），这是定位问题最直接的方法。

5. 检查依赖包还原是否正常 #

虽然dotnet build会自动执行dotnet restore，但如果是私有NuGet源、网络受限（镜像内无法访问外网），会导致还原失败。可在Dockerfile中显式添加dotnet restore步骤并指定源（如有需要）：

RUN dotnet restore "WebApplication1.csproj" --source https://api.nuget.org/v3/index.json

若使用私有源，需确保Docker镜像内配置了正确的NuGet.config文件。

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