Jenkins 不使用新的 MSBuild 還原目標還原 NuGet 包

Question

我們有一個 .net 完整框架 WPF 應用程序，我們已將其從.net 4.6.2 移至 4.7.1 ，並在 csproj 文件中更改為PackageReference而不是 packages.config。

在開發機器上構建似乎沒問題，並且包被下載和恢復，但是當我們使用 Jenkins在我們的Windows Server 2012 構建服務器上構建時，nuget 包似乎沒有正確恢復。

我們使用MSBuild v15.5和最新的“msbuild /restore”命令在構建時恢復包。 注意：使用以前調用“nuget restore”的方法確實有效，但我們現在應該能夠使用msbuild /restore 。

包還原過程似乎正在查看正確的 NuGet 服務器，並且似乎在還原過程中沒有出現錯誤（這是在 Jenkins 上編譯以隔離問題的測試解決方案）：

Restore:
  Restoring packages for c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj...
  Committing restore...
  Generating MSBuild file c:\Jenkins\workspace\Test\ConsoleApp1\obj\ConsoleApp1.csproj.nuget.g.props.
  Generating MSBuild file c:\Jenkins\workspace\Test\ConsoleApp1\obj\ConsoleApp1.csproj.nuget.g.targets.
  Writing lock file to disk. Path: c:\Jenkins\workspace\Test\ConsoleApp1\obj\project.assets.json
  Restore completed in 577.05 ms for c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj.

  NuGet Config files used:
      c:\Jenkins\workspace\Test\NuGet.Config
      C:\Windows\system32\config\systemprofile\AppData\Roaming\NuGet\NuGet.Config

  Feeds used:
      http://devbuild/NuGetHost/nuget
      https://api.nuget.org/v3/index.json
Done Building Project "c:\Jenkins\workspace\Test\ConsoleApp1.sln" (Restore target(s)).

但是當 msbuild 開始編譯代碼時，我們會收到以下錯誤，看起來 NuGet 尚未下載：

CSC : error CS0006: Metadata file 'C:\Windows\system32\config\systemprofile\.nuget\packages\log4net\2.0.8\lib\net45-full\log4net.dll' 
could not be found [c:\Jenkins\workspace\Test\ConsoleApp1\ConsoleApp1.csproj]

知道為什么 nuget 包沒有恢復嗎？

Answer 1

經過數小時的搜索和篩選 NuGet 問題帖子並過濾掉 .net 核心噪音，我有一個修復！

根據提出的一些NuGet和 msbuild msbuild問題，在 Windows Server 2012 的本地系統帳戶下使用 NuGet（或 msbuild /restore）進行還原時，NuGet 使用的文件夾不可訪問，或者由於 32 位和 64 位而成為不同的文件夾正在運行的進程，因此它無法將 nuget 下載到該本地緩存文件夾。

msbuild 在編譯時想要查看的這個文件夾似乎是C:\\Windows\\system32\\config\\systemprofile\\.nuget\\packages 。

我們的解決方案是使用系統范圍的環境變量NUGET_PACKAGES將 NuGet 包緩存文件夾設置為不同的、可訪問的文件夾，例如 C:\\NugetPackageCache 例如

NUGET_PACKAGES=C:\NugetPackageCache

您還可以通過將Build Environment->Inject environment variables to the build process->Properties Content 設置為：

NUGET_PACKAGES=C:/NugetPackageCache

根據this NuGet issue post的另一個潛在解決方案是將環境變量設置為msbuild正在尋找nugets的文件夾，即

NUGET_PACKAGES=C:\Windows\system32\config\systemprofile\.nuget\packages

注意：環境變量優先於 NuGet。 看起來他們還沒有更新NuGet 文檔來提及優先級。

注意：為了注入/設置環境變量，我們使用了EnvInject Jenkins 插件，如下所示：

Answer 2

我們在 .NET Framework 項目上遇到了非常相似但略有不同的情況，最近轉換為 4.7.2 並使用<PackageReference>而不是packages.config ，構建在基於 Windows 的 Jenkins 服務器上，其中服務作為本地系統運行。 在我們的例子中，我們發現nuget restore根本沒有查看我們的私有 MyGet 提要，因此沒有從該源安裝我們自己的包，這導致構建失敗。 在nuget restore命令之后，它沒有顯示在“使用的提要”列表中。

受mips回答的啟發（以及從那里鏈接的 NuGet 問題），我發現問題在於，盡管將C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config作為配置源C:\\Windows\\system32\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config （這確實是我們配置 MyGet 提要的地方），實際上它使用的是C:\\Windows\\SysWOW64\\config\\systemprofile\\AppData\\Roaming\\NuGet\\NuGet.config 。 我能夠通過將 NuGet.config 文件從 system32 位置復制到 SysWOW64 位置來解決該問題。

無需配置和注入 NUGET_PACKAGES 環境變量。

Answer 3

對我們來說，這確實是位的問題！

問題特別在於 MSBuild 實際上是在以下目錄中查找 nuget 包：

C:\Windows\SysWOW64\config\systemprofile\.nuget\packages

即使日志實際上說：

C:\Windows\System32\config\systemprofile\.nuget\packages

因為被調用的 msbuild 是一個運行在 64 位平台上的 32 位進程，當它在 System32 中查找時，它實際上是在查找 SysWOW64。

這是通過文件系統重定向完成的。

我們的解決方案是簡單地調用 64 位版本的 MSBuild，位於：

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\amd64\MSBuild.exe

注意路徑中的amd64 。