ASP.NET Core项目依赖过多致csc启动延迟的原因及优化问询

问题描述 #

我的ASP.NET Core项目详细编译输出如下：

15:35:04:191    1>    C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Roslyn\csc.exe /noconfig /unsafe- /checked- /nowarn:1701,1702,1701,1702,2008 /fullpaths /nostdlib+ /errorreport:prompt /warn:6 /define:TRACE;................ /errorendlocation /preferreduilang:en-US /highentropyva+ /nullable:disable ..........(followed by a whole bunch of project references and files to compile)
15:35:13:317    1>    Microsoft (R) Visual C# Compiler version 4.7.0-3.23517.17 (9d4cc030)
15:35:13:317    1>    Copyright (C) Microsoft Corporation. All rights reserved.

可以看到上述两行日志间存在9秒间隔，即便仅修改Program.cs中的空白内容，该现象也每次都会出现。请问这是否由依赖项目数量过多导致？为何MSBuild未利用缓存加速增量构建？还有其他提速方法吗？

问题分析与解决方案 #

1. 是否由依赖项目过多导致？ #

有可能。从日志时间间隔来看，csc.exe启动前的9秒，主要消耗在MSBuild解析依赖、收集项目引用和编译文件的阶段。如果项目依赖链复杂、引用的项目或NuGet包数量过多，MSBuild需要遍历所有依赖的项目文件、校验依赖状态，这个过程会占用大量时间——哪怕只是修改了空白内容，也可能触发依赖链的全量校验。

2. 为何增量构建未生效？ #

增量构建失效的常见原因包括：

• 项目配置缺陷：自定义目标或任务未正确设置Inputs和Outputs属性，导致MSBuild无法判断哪些内容需要重新构建。
• 文件时间戳异常：项目文件或依赖文件的时间戳被篡改（如跨时区同步、文件系统问题），MSBuild会误判文件已修改，触发全量构建。
• Roslyn缓存异常：默认Roslyn会缓存编译结果，但如果项目使用了/noconfig这类特殊编译选项，或缓存目录权限不足，会导致缓存无法正常使用。
• 依赖项目未配置增量构建：引用的依赖项目本身未启用增量构建，每次都会重新编译，进而触发主项目的重新处理。

3. 提速优化方法 #

• 优化依赖结构：
  • 清理不必要的项目引用和NuGet包，拆分大型项目为更小模块，缩短依赖链。
  • 对无需传递的NuGet依赖，添加<PrivateAssets>all</PrivateAssets>标记，减少MSBuild处理的依赖项数量。
• 修复增量构建配置：
  • 检查项目文件中的自定义任务，确保每个任务都正确设置Inputs和Outputs，让MSBuild能准确判断增量条件。
  • 生成MSBuild二进制日志（添加/bl参数），分析日志中耗时最长的目标或任务，定位增量构建失效的具体环节。
• 优化编译缓存：
  • 显式启用Roslyn共享编译，在项目文件中添加<UseSharedCompilation>true</UseSharedCompilation>（默认已启用，可显式确认）。
  • 清理MSBuild缓存：删除%USERPROFILE%\.nuget\packages下的缓存包，以及%LOCALAPPDATA%\Temp\MSBuild目录下的临时文件。
• 工具层面优化：
  • 使用Visual Studio快速启动（Ctrl+F5）代替调试启动，跳过部分编译检查环节。
  • 升级Visual Studio和.NET SDK到最新版本，新版本通常会优化MSBuild和Roslyn的性能。
  • 启用并行构建：在Visual Studio选项中设置“项目和解决方案->构建并运行->最大并行项目构建数”为CPU核心数，或使用MSBuild的/m参数。

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