Team Build: Der Pfad ‚Pfad‘ ist bereits im Arbeitsbereich ‚Arbeitsbereich‘ Fehler zugeordnet, selbst nachdem alle Arbeitsbereiche auf Build-Agent Löschen

Question

Ich habe dieses Problem, wenn ich einen Build Warteschlange. Der Build wird mit dem Fehler

Der Pfad C: \ [Pfad] \ Sources ist bereits im Arbeitsbereich [Servername] zugeordnet.

die same as this question. aber ich habe alle Arbeitsbereiche auf dem Build-Agenten entfernt, indem Sie diesen Befehl ausführen:

tf workspaces /remove:* 

und auch durch den TFS-Cache-Ordner zu löschen. Ich habe auch den Server neu gestartet, aber der Fehler tritt bei jedem Build auf.

Answer 1

Ok, so endete die Lösung, was posted on here YeahStu ist ziemlich ähnlich hoch. Ich änderte das Arbeitsverzeichnis des Build-Agent von

$(Temp)\UI\$(BuildDefinitionPath) 

zu

$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID) 

Was seltsam ist, dass der andere Build-Agent haben wir noch in $(Temp)\UI\$(BuildDefinitionPath) und arbeiten gut läuft. Der einzige Unterschied zwischen den beiden Agenten ist der, der aufgehört hat zu arbeiten, wenn Visual Studio 2010 RC darauf installiert war, während der, der noch funktioniert, VS2010 Beta2 drauf hat. Keine Ahnung, warum dies einen Unterschied machen sollte.

Answer 2

Mehr Infos über das Arbeitsverzeichnis Eigenschaft hier:

http://msdn.microsoft.com/en-us/library/bb399135.aspx

jedoch in der RTM-Version "$ (homedrive)" wird nicht erkannt. Könnte wegen der Hülle sein; habe es nicht getestet, also sei dir dieses Fehlers in der Dokumentation bewusst.

Answer 3

Ich hatte das gleiche Problem - es lief gut, bis ich VS2010 auf dem Build-Agenten installiert. Das Hinzufügen der BuildDefinitionId hat es behoben, aber es ist seltsam, dass die Installation von VS2010 die bereits eingerichteten und laufenden Arbeitsbereiche durcheinander bringt.

Answer 4

geändert zu

$ (Temp) \ UI \ $ (BuildDefinitionPath) \ $ (BuildDefinitionID)

macht es funktioniert, aber nicht für 100% Situationen. Jedes Mal, wenn der Build nicht abgeschlossen werden konnte (z. B. ein Fehler in Quellcodes oder etwas), wird nach dem Beheben des Fehlers und dem Versuch, Teambuild erneut auszuführen, die Aktion "Arbeitsbereich XYZ ist bereits zugeordnet" fehlgeschlagen Workspace-Mapping von "Team Foundation Sidekick 2010" und führe erneut Teambuilding durch, um erfolgreich zu sein. Das nächste Mal, wenn ein Team-Build mehr als einmal ausgeführt wird, wird erfolgreich aufgebaut, aber bis einige Team-Builds aufgrund eines Fehlers im Quellcode fehlschlagen, fängt es wieder an, "Workspace Mapping" -Fehler zu verursachen.

Es scheint mir, dass TFS 2010 einige Fehler hat, wenn einige Team-Build fehlschlägt, ist es nicht klar/löschen Arbeitsbereich verwendet wird, oder etwas ähnliches.

Haben jemand gleichen Probleme auftreten?

Answer 5

Ich denke, das Problem nur angezeigt, wenn Sie mehr als ein Build-Agenten auf einer Build-Box haben.

Answer 6

Ich denke, Ihr Problem vielleicht mit 3 Build-Agenten zu tun, die nicht getaggt sind. Ich denke, der Arbeitsbereich wird, wenn er zurückgelassen wird, von dem Agenten gelöscht, der den Build ausführt. Wenn es sich um einen anderen Agenten als den Agenten handelt, der den Arbeitsbereich erstellt hat, treten offensichtliche Probleme auf.

Also das Problem beheben Sie folgendes tun müssen. Namen Ein Agent der Standard-Agent. Dies wird keine Tags haben. In den beiden anderen Agenten, einen Tag für die Agenten in Eigenschaften hinzufügen, Einen für jeden Agenten und wählt.

Jedes Build, das ausgeführt wird und kein Tag-Set hat, verwendet immer den Default Agent.

Um einen Build zu erhalten, der einen der anderen Agenten verwendet, öffnen Sie die Build-Definition und gehen zum erweiterten Abschnitt in Process.

Öffnen Sie die Agenteneinstellungen und wählen Sie die Auslassungszeichen im Tags-Filter aus und geben Sie ein Tag mit dem gleichen Namen für das Tag ein, das Sie im Build-Agenten eingeben.

Möglicherweise müssen Sie die Arbeitsbereiche vor dem ersten Ausführen bereinigen.

Dadurch können Sie steuern, welcher Buildagent für jede Builddefinition verwendet wird. Daher sollten Sie auch das Problem mit dem Arbeitsbereich beheben.

Answer 7

http://www.devaffair.com/2011/11/path-is-already-mapped-in-workspace.html

Nun, eigentlich ist dieses Problem in einigen anderen Fragen in dieser Seite gelöst, aber ich werde meine Antwort schreiben wieder :)

Dieser Link führt Sie zu einem Blog direkt die wahrscheinlich Ihr Problem lösen die schnellste

Answer 8

konnte ich den Arbeitsbereich entfernen. Führen Sie auf dem Buildserver folgende Schritte aus:

Laden Sie psExec von sysinternals herunter.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Öffnen Sie cmd als Administrator.

Führen Sie psexec aus, um cmd als Netzwerkdienst zu öffnen.
psexec -i -u "nt-berechtigung \ netzwerkdienst" cmd.exe Das öffnet ein anderes cmd-Fenster, das "nt authority \ network service" verwendet.

Führen Sie ein "whoami" aus, um sicherzustellen, dass Sie jetzt "nt authority \ network service" sind.

Öffnen Sie Visual Studio, indem Sie devenv.

in Visual \ Team Explorer-Studio, eine Verbindung mit dem Source-Control-Server

Innerhalb \ Source-Control-Explorer von Visual Studio, wegzuwerfen die beanstandeten Workspaces.

Ich habe keine Ahnung warum, aber die tf Workspaces/remove funktionierte nicht für mich.