Jenkins ne restaure pas les packages NuGet avec une nouvelle cible de restauration MSBuild
Nous avons une application WPF de framework complet .net que nous sommes passés de . Net 4.6.2 à 4.7.1 avec changement à PackageReference dans le fichier csproj au lieu de packages.config.
Construire sur les machines de développement semble bien et les packages sont téléchargés et restaurés, mais lorsque nous construisons sur notre serveur de build Windows Server 2012 avec Jenkins , le nuget les paquets ne semblent pas être restaurés correctement.
Nous utilisons MSBuild v15.5 avec le dernier "msbuild/restore" commande pour restaurer les packages au moment de la construction. Remarque: L'utilisation de la façon précédente d'appeler "restauration de nuget" fonctionne , mais nous devrions pouvoir utiliser msbuild/restore maintenant =.
Le processus de restauration du package semble rechercher les serveurs NuGet corrects et semble passer par la restauration sans erreur (il s'agit d'une solution de test compilée sur Jenkins pour isoler le problème):
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)).
Mais lorsque msbuild vient de compiler le code, nous obtenons les erreurs suivantes qui semblent que le NuGet n'a pas été téléchargé:
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]
Une idée pourquoi les paquets nuget ne sont pas restaurés?
Après plusieurs heures de recherche et de filtrage dans les publications de problèmes NuGet et de filtrage du bruit de base .net, j'ai un correctif!
Selon certains NuGet et msbuild msbuild problèmes soulevés, lors de la restauration avec NuGet (ou msbuild/restore) sous le compte système local dans Windows Server 2012, le dossier que NuGet utilise n'est pas '' t accessible ou c'est un dossier différent en raison du processus 32 bits vs 64 bits qui s'exécute donc il ne peut pas télécharger de nugets dans ce dossier de cache local.
Ce dossier que msbuild souhaite consulter au moment de la compilation semble être C:\Windows\system32\config\systemprofile\.nuget\packages .
La solution pour nous a été de définir le dossier de cache du package NuGet en utilisant la variable d'environnement à l'échelle du système NUGET_PACKAGES dans un dossier différent et accessible tel que C:\NugetPackageCache, par exemple
NUGET_PACKAGES=C:\NugetPackageCache
Vous pouvez également définir cela par projet Jenkins en définissant Environnement de construction-> Injecter les variables d'environnement au processus de construction-> Propriétés Contenu sur:
NUGET_PACKAGES=C:/NugetPackageCache
Une autre solution potentielle en fonction de cela NuGet issue post est de définir la variable d'environnement dans le dossier que msbuild recherche pour les pépites, c'est-à-dire
NUGET_PACKAGES=C:\Windows\system32\config\systemprofile\.nuget\packages
Remarque: Les variables d'environnement ont priorité avec NuGet. Il ne semble pas qu'ils aient mis à jour les documents NuGet pour mentionnez la priorité .
Remarque: Pour injecter/définir les variables d'environnement, nous utilisons le plugin EnvInject Jenkins qui ressemble à ceci:
Nous avions une situation très similaire mais légèrement différente sur un projet .NET Framework, récemment converti à la fois en 4.7.2 et en utilisant <PackageReference> plutôt que packages.config, en s'appuyant sur des serveurs Jenkins basés sur Windows où le service s'exécute en tant que système local. Dans notre cas, nous avons constaté que nuget restore ne regardait tout simplement pas notre flux MyGet privé, et par conséquent n'installait pas nos propres packages à partir de cette source, ce qui a échoué à la construction. Il n'apparaissait pas dans la liste des "flux utilisés" après un nuget restore commande.
Inspiré par mips réponse ici (et les problèmes NuGet liés à partir de là), j'ai découvert que le problème était que, malgré la liste C:\Windows\system32\config\systemprofile\AppData\Roaming\NuGet\NuGet.config comme source de configuration (qui était en effet l'endroit où notre flux MyGet était configuré), en fait, il utilisait C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\NuGet.config au lieu. J'ai pu résoudre le problème en copiant le fichier NuGet.config de l'emplacement system32 vers l'emplacement SysWOW64.
Il n'était pas nécessaire de configurer et d'injecter une variable d'environnement NUGET_PACKAGES.