web-dev-qa-db-fra.com

Le mystère des processus msbuild.exe bloqués inactifs, des stylets verrouillés Stylecop.dll, Nuget AccessViolationException et CI en conflit

Observations:

  • Sur notre serveur de génération Jenkins, nous voyions beaucoup de processus msbuild.exe (~ 100) traîner après la fin du travail, avec une utilisation de mémoire d’environ 20 Mo et une activité de 0% de l’UC.

  • Les constructions utilisant différentes versions de stylecop étaient par intermittence en échec:

    workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7): error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task. Verify the parameter exists on the task, and it is a gettable public instance property. 

  • Nuget.exe était par intermittence sortant avec l'erreur de violation d'accès suivante (0x0000005):

    .\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages" exited with code -1073741819.

MsBuild a été lancé de la manière suivante via un travail Jenkins Matrix, avec 'BuildInParallel' activé:

    `msbuild /t:%Targets% /m
    /p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
    JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
    Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
msbuildnugetstylecop
54
Jon Rea

Après beaucoup de fouilles et d’essais sans suite, j’ai finalement créé une nouvelle solution minimale reproduisant le problème sans autre solution. sur. Le problème s’est révélé être dû à la parallélisation multi-cœur de msbuild - le paramètre 'm'.

  • Le paramètre 'm' indique à msbuild de générer des "nœuds", ceux-ci resteront actifs une fois la génération terminée et seront ensuite réutilisés par les nouvelles générations!
  • L'erreur 'ViolationCount' de StyleCop a été provoquée par une version donnée réutilisant une ancienne version de stylecop.dll à partir de l'espace de travail d'une autre version, où ViolationCount n'était pas pris en charge. C'était étrange, car l'espace de travail de CI ne contenait que la nouvelle version. Il semble qu'une fois que StyleCop.dll a été chargé dans un nœud MsBuild donné, il reste chargé pour la prochaine génération. Je ne peux que supposer que cela est dû au fait que StyleCop charge une sorte de singleton dans les processus de nœuds? Cela explique également le verrouillage de fichier entre les générations.
  • Le crash de la violation d'accès au nuget a maintenant disparu (sans autre changement), il est donc évidemment lié au problème de réutilisation du noeud ci-dessus.
  • Par défaut, le paramètre 'm' indique le nombre de cœurs: nous voyions 24 instances de construction créées sur notre serveur de génération pour un travail donné.

Les messages suivants ont été utiles:

Le correctif:

  • Ajoutez la ligne set MSBUILDDISABLENODEREUSE=1 au fichier de commandes qui lance msbuild
  • Lancer msbuild avec /m:4 /nr:false
  • Le paramètre "nr" indique à msbuild de ne pas utiliser "Node Reuse" - les instances de msbuild sont donc fermées une fois la construction terminée et ne sont plus en conflit, ce qui entraîne les erreurs ci-dessus.
  • Le paramètre 'm' est défini sur 4 pour arrêter trop de nœuds générés par tâche.
71
Jon Rea

J'ai eu le même problème. Une ancienne référence que j'ai trouvée était dans les fichiers csproj

<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>

De plus, j'ai supprimé l'intégralité du dossier "Packages" qui se trouve dans le même dossier que le fichier sln après avoir fermé Visual Studio. Cela a amené VS à reconstruire le dossier et à lâcher le cache de l'ancienne version de stylecop

1
Jin

J'ai eu le même problème pendant un certain temps, les builds prenaient plus de 6 minutes à terminer après quelques recherches. J'ai trouvé notre erreur de réutilisation des nœuds. Nous avons donc ajouté/m: 4/nr: false en corrigeant mon problème immédiatement. 

0
Ala'a Hamad