NuGet-Fehler in TeamCity: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird

8

Wir verwenden TeamCity (9.0) als unseren CI-Server, um mehrere Anwendungen zu erstellen, zu testen und bereitzustellen. In letzter Zeit sehen wir gelegentliche NuGet (2.8.3) -Fehler wie folgt: (einer von allen 30/40 Builds oder so):

  

[restore] Der Prozess kann nicht auf die Datei 'C: \ BuildAgent \ work \ e32cbd0940f38bf ..... \ packages \ Newtonsoft.Json.5.0.6 \ Newtonsoft.Json.5.0.6.nupkg' zugreifen, da dies der Fall ist von einem anderen Prozess verwendet werden.

wo das tatsächliche Paket von Zeit zu Zeit zu unterscheiden scheint.

Wir haben vermutet, dass es etwas damit zu tun hat, dass dasselbe Paket in mehreren Projekten innerhalb derselben Lösung referenziert wird, aber ich erwarte, dass NuGet dies richtig handhaben kann, indem Duplikate herausgefiltert werden, anstatt das gleiche Paket mehrmals abzurufen und endet mit Schreibsperren beim Wiederherstellen der Pakete im Arbeitsordner.

Als ersten Schritt jeder Build-Konfiguration haben wir einen 'NuGet Installer' Schritt auf 'Restore' gesetzt. Ich habe versucht, an seinen Einstellungen zu fummeln (verschiedene 'Update-Modi', '-NoCache', ältere NuGet-Version (2.8.0)), aber ohne Erfolg.

Hat jemand andere ähnliche Probleme erfahren, und wenn ja, hat er Vorschläge, wie Sie sicherstellen können, dass dieser Fehler nicht auftritt.

Jede Hilfe würde sehr geschätzt werden!

    
Jiri 30.12.2014, 08:03
quelle

4 Antworten

9

Ich hatte das gleiche Problem mit Jenkins und habe behoben, dass durch Hinzufügen von "-DisableParallelProcessing" zum Befehl nuget restore der letzte Befehl wie folgt aussehen würde:

%Vor%     
glm 27.07.2015 21:46
quelle
2

Das Ausschließen von NuGet-Paketdateien von unseren Anti-Malware-Produkten hat dieses Problem für uns behoben.

Ich habe das Dienstprogramm SysInternals Process Explorer auf den Erstellungsagenten verwendet, um nach Dateihandles für zu suchen irgendwelche * .nupkg Dateien, während die Builds ausgeführt wurden. Nach mehreren Builds habe ich beobachtet, wie die Anti-Malware-Produkte diese Dateien während der NuGet-Wiederherstellungsvorgänge kurz gesperrt haben. Das Hinzufügen eines Ausschlusses zu den Anti-Malware-Scanregeln verhinderte diese Sperren, da die Dateien nicht mehr gescannt wurden.

In unserer Umgebung verwenden wir zwei verschiedene Anti-Malware-Produkte auf verschiedenen Build-Agent-Servern. Bei beiden Produkten sind wir auf dieses Problem gestoßen.

    
Adam D 04.02.2015 19:26
quelle
0

Was die Fehlermeldung betrifft, habe ich sie auch gefunden.

Ich habe den "nuget restore" -Prozess bereinigt, an der Stelle, an der das .nupkg in das lokale Repository kopiert wurde, und dann den Thread eingefroren, während die Datei zum Schreiben geöffnet wurde. Und tatsächlich habe ich die Ausnahme in einer anderen Aufgabe bekommen, aufgrund der Tatsache, dass die beiden Pakete Ids hatten, wobei eine die Präfix der anderen war. Ich habe ein Problem dafür eingereicht: Ссылка .

Das ist aber wahrscheinlich nicht genau Ihr Problem, da der Fehler in meinem Fall darin besteht, den .nupkg des Pakets mit dem "langen" Namen zu lesen, und ich glaube nicht, dass es da ist ein Paket mit einer ID, die ein Präfix von NewtonSoft.Json ist (während es andersherum sehr gut möglich ist: es gibt zum Beispiel NewtonSoft.JsonResult von NewtonSoft.Json.Glimpse).

    
Jean-Jacques Lafay 04.03.2015 15:04
quelle
-2

Sie können die Build-Funktion Swabra mit der Option "Locking processes" aktivieren. (erfordert handle.exe). Und überprüfen Sie, ob Dateien nach dem Ende des Builds gesperrt sind oder nicht. Wenn keine gesperrten Dateien vorhanden sind, versuchen Sie, Nuget über den Befehlszeilen-Build-Schritt auszuführen NuGet-Installationsprogramm. Wenn das Problem reproduziert wird, dann bedeutet dies höchstwahrscheinlich, dass das Problem mit NuGet zusammenhängt.

    
Alina Mishina 16.01.2015 12:53
quelle

Tags und Links