Der TeamCity NuGet Installer-Schritt schlägt fehl

8

Dieser Fehler tritt manchmal auf, normalerweise funktioniert dieser Schritt gut, aber in ungefähr 10% Fällen versagt er mit der folgenden Nachricht.

Der Nuget-Installer-Schritt ist der erste Build-Schritt, und auch "Clean Checkout" ist in TeamCity aktiviert, daher sollte es keinen Prozess geben, der Datei verwendet.

  

[restore] Der Prozess kann nicht auf die Datei 'C: \ BuildAgent \ work ... \ packages \ Microsoft.Bcl.Build.1.0.21 \ Microsoft.Bcl.Build.1.0.21.nupkg' zugreifen, da dies der Fall ist von einem anderen Prozess verwendet werden.

     

[restore] Prozess beendet mit Code 1

    
Lev 01.02.2016, 10:28
quelle

3 Antworten

6

Hauptursache von " meine Datei wird von einem anderen Prozess verwendet "

Je nachdem, was die Ursache ist, können Sie verschiedene Dinge tun:

  • Sie verwenden die parallele Build-Funktion von MSBuild: Laut seinem Blog , Es scheint nicht gut mit NuGet-Paketwiederherstellung zu funktionieren, da es parallel Paketwiederherstellung für jedes Projekt ausführen kann (und wenn mehrere Projekte Microsoft.Bcl.Build erfordern ... Boom!). Deaktivieren Sie den parallelen Build oder führen Sie eine Paketwiederherstellung außerhalb der Lösung durch (in einem Befehlszeilenschritt). Übrigens, es ist keine gute Methode, NuGet-Wiederherstellung mit der Lösung MSBuild durchzuführen .

  • Es gibt einen anderen Prozess:
    Verwenden Sie den Prozessmonitor / -explorer, um zu finden aus welchem ​​Prozess halten Sie die Sperre für die Datei. Es könnte sich um ein Antivirenprogramm, eine Dateiindizierung, eine zusätzliche Build-Agent-Instanz handeln, die im Hintergrund läuft. Da die Sperre nicht permanent ist und 1 von 10 für diese Art von Problem ziemlich viel ist, würde ich nicht wetten, dass dies die Hauptursache ist.

  • Es gibt keinen anderen Prozess:
    Es ist ein Fehler im Teamcity NuGet Installer, der etwas bewirkt. Dann könnten Sie den Schritt durch einen Befehlszeilenschritt mit einem Aufruf von nuget restore ersetzen und prüfen, ob er Ihr Problem behebt.

  • Bestimmen Sie sich selbst mit einem Nuget-Plugin Ihrer Geschmacksrichtung: Der NuGet-Plugin-Code ist hier verfügbar. Das bedeutet, dass Sie eine eigene Version kompilieren können, mit zusätzlichen Debugging-Informationen, wenn diese Art von Problem auftritt (Liste der Prozesse, die die Datei beispielsweise sperren). Oder noch nützlicher, Sie können einen Wiederholungsschritt hinzufügen, falls die Datei gesperrt ist.

BEARBEITEN: Für diejenigen, die Teamcity unter Unix verwenden ...

Ich habe versucht, Teamcity unter Unix zu installieren und mono mit dem NuGet-Plugin zu erstellen. Das NuGet-Plugin funktioniert übrigens unter Unix überhaupt nicht (es wird von JetBrains nicht unterstützt). Ich habe sogar versucht, es zu reparieren, aber es war einfacher, es einfach durch eine Befehlszeile zu ersetzen.

    
Fab 12.02.2016, 13:19
quelle
3

Haben Sie ein separates Arbeitsverzeichnis für jeden Build-Agent? Sonst könnten zwei Paralell-Builds gleichzeitig ausgeführt werden.

    
mano 01.02.2016 10:46
quelle
2

Versuchen Sie Folgendes:

  1. Fügen Sie einen speziellen Build-Schritt in TeamCity hinzu, der ausgeführt wird, wenn "Selbst wenn einige der vorherigen Schritte fehlgeschlagen sind" . ( Ссылка )
  2. Ermitteln Sie in diesem Build-Schritt, welcher Prozess eine Datei sperrt und im Protokoll ausgibt. ( Wie finde ich heraus Welcher Prozess sperrt eine Datei mit .NET? )
DmitryZyr 18.02.2016 19:27
quelle