為什么“DotNetCore”構建任務這么慢？

Question

我們有許多 .Net Framework 4.x 解決方案，其中一些最近遷移到了 .Net 6。作為這項工作的一部分，我為新解決方案創建了構建管道，但是與構建相比，這些管道非常慢.Net Framework 解決方案。

慢構建任務是“.Net Core”（“DotNetCoreCLI@2”），用在三個地方：“restore”命令恢復解決方案的NuGet包，“build”命令構建解決方案，“test”命令運行解決方案的單元測試項目。

以一個解決方案為例（大約 50 個項目），這些是大概的時間安排：

• 恢復：1m20s
• 建築：3m
• 單元測試：3m

這是大約。 構建 .Net Framework 解決方案的時間，您可以看到速度要快得多：

• 恢復：9s - 使用“NuGet”（“NuGetCommand@2”）任務
• build: 1m13s - 使用“Visual Studio Build”（“VSBuild@1”）任務
• 單元測試：40 秒 - 使用“Visual Studio 測試”（“VSTest@2”）任務

我相信后兩個任務使用 VS2019（安裝在我們的本地 Azure DevOps 服務器上），我最近發現了這個第 3 方市場構建任務，它是這些任務的 VS2022 等價物。 我已經更新了 .Net6 構建管道以使用這些而不是“DotNetCoreCLI@2”構建和測試任務（並且我恢復為使用“NuGetCommand@2”進行恢復）。 現在的時間與 .Net Framework 構建管道相當：

• 恢復：10 秒（“NuGetCommand@2”）
• 構建：50s（市場任務）
• 單元測試：32s（市場任務）

我寧願使用內置任務而不是市場任務，但為什么“DotNetCoreCLI”任務這么慢？ 我是不是遺漏了一些關於配置的東西，或者這只是更新技術並不總是等同於改進性能的情況？！

Answer 1

Visual Studio 任務非常繁重，主要用於遺留支持。

跳轉到現代 .NET 時，規則 #1 是忘掉有關構建項目的舊方法的所有內容。 使用 .NET 6 時，使用do.net CLI 從 NuGet package 恢復 ( do.net restore ) 到測試 ( do.net test ) 和發布工件 ( do.net publish <ARGS> )，您將獲得更好的體驗. 將構建管道中的那些與 UseDotNet@2 和 DotNetCoreCLI@2 管道任務一起使用。

非常重要的一點是，在 Azure DevOps 中，您可以緩存 NuGet 依賴項，這樣您就不必下載它們，除非它們發生變化。