Jenkins не восстанавливает пакеты NuGet с новой целью восстановления MSBuild

У нас есть полнофункциональное WPF-приложение .net, которое мы переместили с .net 4.6.2 на 4.7.1 вместе с изменением PackageReference в файле csproj вместо packages.config.

Сборка на машинах разработки, кажется, хорошо, и пакеты загружаются и восстанавливаются, но когда мы собираемся на нашем сервере сборки Windows Server 2012 с Jenkins, пакеты nuget, похоже, не восстанавливаются правильно.

Мы используем MSBuild v15.5 с последней командой "msbuild/restore" для восстановления пакетов во время сборки. Примечание: Используя предыдущий способ вызова "NuGet восстановления" делает работу, но мы должны быть в состоянии использовать MSBuild/восстановление в настоящее время.

Кажется, процесс восстановления пакета просматривает правильные серверы 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 не восстанавливаются?

Ответ 1

После многих часов поиска и отсеивания сообщений о проблемах NuGet и фильтрации шума ядра .net у меня есть исправление!

В соответствии с некоторыми проблемами, связанными с NuGet и msbuild msbuild, при восстановлении с помощью NuGet (или msbuild/restore) под локальной системной учетной записью в Windows Server 2012 папка, используемая NuGet, недоступна или является другой папкой из-за того, что 32-разрядная версия отличается от 64-разрядной. процесс, который выполняется, поэтому он не может загружать нюансы в эту папку локального кэша.

Эта папка, которую msbuild хочет просмотреть во время компиляции, выглядит как C:\Windows\system32\config\systemprofile\.nuget\packages.

Для нас было решено установить папку кэша пакета NuGet, используя общесистемную переменную среды NUGET_PACKAGES, в другую доступную папку, например C:\NugetPackageCache, например:

NUGET_PACKAGES=C:\NugetPackageCache

Вы также можете установить это для проекта Jenkins, установив переменные среды Build Environment-> Inject для сборки process-> Properties Content в:

NUGET_PACKAGES=C:/NugetPackageCache

Согласно этому сообщению о проблеме NuGet, еще одно потенциальное решение - установить переменную окружения в папку, в которой msbuild ищет нюгетеры, т.е.

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

Примечание. Переменные среды имеют приоритет над NuGet. Похоже, они еще не обновили документы NuGet, чтобы упомянуть приоритет.

Примечание. Для ввода/установки переменных среды мы используем плагин EnvInject Jenkins, который выглядит следующим образом:

Jenkins plugin with environment variables

Ответ 2

У нас была очень похожая, но немного другая ситуация в проекте .NET Framework, недавно преобразованном как в 4.7.2, так и в использование <PackageReference> а не packages.config, основанного на серверах Jenkins на базе Windows, где служба работает как локальная система. В нашем случае мы обнаружили, что nuget restore nuget просто не рассматривало нашу личную ленту MyGet, и, следовательно, не устанавливало наши собственные пакеты из этого источника, что не удалось собрать. Он не отображался в списке "использованных каналов" после команды nuget restore.

Вдохновленный ответом mips здесь (и связанными с ним проблемами NuGet), я обнаружил, что проблема заключалась в том, что, несмотря на перечисление 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.