web-dev-qa-db-de.com

Das Mysterium stecken inaktiver msbuild.exe-Prozesse, gesperrter Stylecop.dll, Nuget AccessViolationException und CI-Builds stoßen miteinander zusammen

Beobachtungen:

  • Auf unserem Jenkins-Build-Server sahen wir nach Abschluss der Jobs eine Menge msbuild.exe-Prozesse (~ 100) mit rund 20 MB Arbeitsspeicher und 0% CPU-Aktivität.

  • Builds mit verschiedenen Versionen von stylecop waren zeitweise fehlgeschlagen:

    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 wurde zeitweise mit dem folgenden Zugriffsverletzungsfehler (0x0000005) beendet:

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

MsBuild wurde auf folgende Weise über einen Jenkins Matrix-Job mit aktiviertem 'BuildInParallel' gestartet:

    `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`
54
Jon Rea

Nach einem Los des Umgraben und Ausprobieren verschiedener Dinge ohne Erfolg, schuf ich schließlich eine neue Minimallösung, die das Problem reproduzierte, wobei sehr wenig anderes vor sich ging. Es stellte sich heraus, dass das Problem durch die Multi-Core-Parallelisierung von msbuild verursacht wurde - den Parameter 'm'.

  • Der Parameter 'm' teilt msbuild mit, "Knoten" zu erzeugen. Diese bleiben nach Beendigung des Builds aktiv und werden von neuen Builds wieder verwendet.
  • Der StyleCop-Fehler "ViolationCount" wurde verursacht, indem ein bestimmter Build eine alte Version der stylecop.dll aus einem anderen Arbeitsbereich des Builds wiederverwendete, wobei ViolationCount nicht unterstützt wurde. Dies war merkwürdig, da der CI-Arbeitsbereich nur die neue Version enthielt. Es scheint, dass die StyleCop.dll nach dem Laden in einen bestimmten MsBuild-Knoten für den nächsten Build geladen bleibt. Ich kann nur davon ausgehen, dass StyleCop eine Art Singleton in die Knotenprozesse lädt. Dies erklärt auch das Sperren von Dateien zwischen Builds.
  • Der Absturz der Nuget-Zugriffsverletzung ist nun verschwunden (ohne weitere Änderungen) und hängt daher offensichtlich mit dem oben genannten Problem der Wiederverwendung von Knoten zusammen.
  • Da der Parameter 'm' standardmäßig auf die Anzahl der Kerne eingestellt ist, wurden auf einem Build-Server 24 msbuild-Instanzen für einen bestimmten Job erstellt.

Die folgenden Beiträge waren hilfreich:

Die Reparatur:

  • Fügen Sie der Batchdatei, die msbuild startet, die Zeile set MSBUILDDISABLENODEREUSE=1 hinzu
  • Msbuild mit /m:4 /nr:false starten
  • Der 'nr' -Parameter weist msbuild an, "Node Reuse" nicht zu verwenden - also werden msbuild-Instanzen nach Abschluss des Builds geschlossen und kollidieren nicht mehr miteinander - was zu den oben genannten Fehlern führt.
  • Der Parameter 'm' ist auf 4 gesetzt, um zu verhindern, dass zu viele Knoten pro Job erscheinen
66
Jon Rea

Ich hatte das gleiche Problem. Eine alte Referenz fand ich in Csproj-Dateien

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

Ich habe auch den gesamten "Packages" -Ordner gelöscht, der sich im selben Ordner wie die sln-Datei befindet, nachdem ich das Visual Studio geschlossen habe. Es löste VS aus, den Ordner neu zu erstellen und den Cache der alten Version von stylecop loszulassen

1
Jin

Ich hatte das gleiche Problem für eine Weile, Builds dauerten über 6 Minuten, um zu beenden. Nach einigem Graben fand ich, dass unser Knoten wiederverwendet wurde. Durch Hinzufügen von/m: 4/nr: false wurde mein Problem sofort behoben 

0
Ala'a Hamad