.NET Core从1.1升级到2.0后Cygwin下构建变慢重复构建求助

嘿，我之前升级.NET Core版本时也碰到过类似的增量构建失效问题，结合你的情况，咱们来一步步排查解决：

1. 独立构建进程导致缓存不共享 #

你的脚本里是**多次单独调用dotnet build**来构建每个项目，而.NET Core 2.0的MSBuild增量构建缓存是进程级的——每次dotnet build启动新进程，无法共享之前构建proj_core的缓存结果。所以构建proj1时会先编译proj_core，构建proj2时又会重新检查并编译proj_core，导致重复工作。

解决方案： #

改用一次性构建多个项目，或者基于解决方案文件构建，让MSBuild统一管理依赖和缓存：

• 如果有解决方案文件（.sln），直接构建整个解决方案：

  dotnet build MySolution.sln --configuration Debug --output "../bin" --framework $NETCOREVER
  

• 没有sln的话，一次性传入多个项目文件：

  dotnet build proj1.csproj proj2.csproj --configuration Debug --output "../bin" --framework $NETCOREVER
  

这样MSBuild会一次性解析所有依赖，只会编译需要更新的部分，避免重复构建proj_core。

2. 共享输出目录干扰增量检测 #

.NET Core 2.0对输出目录的文件追踪逻辑更严格，所有项目都输出到同一个../bin目录时，不同项目的文件可能互相干扰，导致MSBuild误判文件状态，触发不必要的重建。

解决方案： #

给每个项目指定独立的输出子目录，比如修改build_one_proj函数：

build_one_proj() {
  local PROJECT_NAME=$1
  dotnet build "$PROJECT_NAME.csproj" --configuration Debug --output "../bin/$PROJECT_NAME" --framework $NETCOREVER
}

这样每个项目的输出文件分开，MSBuild能更准确地判断哪些文件是最新的。

3. 检查项目文件的构建配置变化 #

升级到.NET Core 2.0后，proj_core的.csproj文件可能引入了新的构建目标、依赖项，或者某些自定义任务没有正确设置增量检测规则，导致每次构建都触发proj_core重建。

验证方法： #

运行带详细日志的构建命令，查看proj_core被标记为重建的原因：

dotnet build proj1.csproj -v detailed

在日志里搜索Building target "CoreBuild" completely之类的关键词，找到触发重建的具体文件或条件，针对性调整。

4. Cygwin路径格式的兼容性问题 #

Cygwin的Unix风格路径可能和MSBuild的Windows路径处理逻辑冲突，导致文件修改时间、依赖路径的判断出错，进而触发全量构建。

解决方案： #

在脚本中使用Windows风格的路径，或者用cygpath转换路径：

# 转换输出目录为Windows路径
WIN_OUTPUT=$(cygpath -w "../bin")
dotnet build --configuration Debug --output "$WIN_OUTPUT" --framework $NETCOREVER

你可以先试试第一种方案（统一构建多个项目），这是最常见的解决这类问题的方法，应该能快速缩短构建时间～

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