为何DotNetCoreCLI@2构建任务运行速度如此缓慢？

1. 底层执行引擎的差异 #

VSBuild@1和VSTest@2直接调用本地安装的Visual Studio自带MSBuild、VSTest引擎——这些引擎针对Windows平台做了深度优化，还能复用VS安装时配置的本地组件缓存、集成调度优势。而DotNetCoreCLI@2默认使用.NET SDK自带的dotnet msbuild，它是跨平台轻量化版本，在Windows环境下缺少VS版MSBuild的平台特定优化，比如文件系统访问效率、并行构建调度逻辑都有差距。

2. NuGet还原的缓存与解析策略不同 #

NuGetCommand@2与VS的缓存体系深度绑定，直接复用%USERPROFILE%\.nuget\packages本地缓存。dotnet restore虽然也使用该缓存，但如果管道使用的SDK版本与本地VS配套SDK版本不匹配，可能触发额外的缓存验证、重新下载逻辑；或默认启用了更严格的依赖解析检查，导致耗时增加。

3. 并行执行的默认配置差异 #

VSBuild默认会根据CPU核心数启用高并行度构建，而dotnet build默认并行度较低，需手动配置参数才能达到同等效率。同样，dotnet test默认的并行规则（进程/线程级并行）与VSTest@2的优化策略不同，后者能更充分利用本地硬件资源。

针对dotnet restore #

• 显式绑定本地NuGet缓存：添加参数--no-cache=false（确保缓存路径正确），或设置环境变量NUGET_PACKAGES指向本地缓存目录。
• 固定依赖版本场景下，用--locked-mode跳过冗余依赖解析：dotnet restore --locked-mode。

针对dotnet build #

• 启用最大并行构建：添加--maxcpucount（自动匹配CPU核心数）或指定具体数值--maxcpucount:8。
• 已单独执行restore步骤时，添加--no-restore避免重复执行。
• 添加--verbosity minimal减少日志输出，降低IO开销。
• Windows环境下，设置环境变量MSBUILD_EXE_PATH指向VS安装的MSBuild.exe（例如C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe），让dotnet build调用VS优化版引擎。

针对dotnet test #

• 启用进程级并行：添加--parallel参数，配合测试配置文件（在文件中设置RunConfiguration/ParallelizeTestCollections=true）。
• 已单独执行build步骤时，添加--no-build跳过构建环节。
• 添加--verbosity minimal减少日志输出。
• Windows环境下，设置VSTEST_HOST_PATH指向VS的VSTest.Console.exe，让dotnet test调用VS的测试引擎。

代理环境配置 #

• 确保代理服务器安装与.NET 6配套的VS2022（至少安装VS Build Tools 2022），让dotnet命令复用VS的本地组件缓存与优化。
• 清理代理上的旧SDK版本，避免版本切换带来的额外开销。

新技术并非在所有场景下都比旧技术高效：.NET SDK的dotnet命令主打跨平台一致性，而VS系列任务则针对Windows平台做了深度优化。通过调整内置任务的参数，复用VS本地的优化引擎，完全可以让DotNetCoreCLI@2的性能接近第三方任务或VSBuild/VSTest的水平。

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