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. Die Build-Werkzeuge mit dem Fehler

  

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

gleiche wie diese Frage . aber ich habe entfernt alle Arbeitsbereiche auf dem Build-Agenten mit dem folgenden Befehl:

tf workspaces /remove:*

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

Answer 1

Ok, so dass die Lösung endete als ziemlich ähnlich, was YeahStu hier gepostet auf. Ich änderte das Build-Agenten des Arbeitsverzeichnis von

$(Temp)\UI\$(BuildDefinitionPath)

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

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

Answer 2

http: //blog.devaffair .com / 2011/11 / Weg-ist-schon-Mapped-in-workspace.html

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

Dieser Link führt Sie zu einem Blog lenken, die wahrscheinlich das Problem der schnellste

lösen

Answer 3

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

Answer 4

Ich denke, Ihr problm vielleicht mit mit 3 Build-Agenten zu tun, die nicht markiert sind. Ich denke, dass der Arbeitsbereich, wenn hinter sich gelassen, die vom Agenten gelöscht wird, die die Build tut. Wenn es ein anderes Mittel an die Agenten, die den Arbeitsbereich erstellt, dann wird es offensichtlich Probleme sein.

So das Problem beheben Sie folgende tun müssen. Nennen Sie einen Agent die Standard-Agent. Dies hat keine Tags. In den beiden anderen Agenten, in Eigenschaften fügen Sie einen Tag für die Agenten, Eine für jeden Agenten und wählen Sie das.

Nun kann jeder bauen, die ausgeführt wird, die keinen Tag-Satz hat immer die Standard-Agent verwenden.

Um eine Ansammlung eines der anderen Mittel zu verwenden, öffnen Sie die Builddefinition und liest den erweiterten Abschnitt in Prozess.

öffnen Sie die Agent-Einstellungen und die Auslassungspunkte in Stichworten Filter auswählen und einen Tages mit dem gleichen Namen für die den Tag auf dem Build-Agenten Sie eingegeben eingeben können.

Sie müssen die Arbeitsbereiche vor dem ersten Lauf klären.

Doing die oben können Sie steuern, welche Build-Agent für jede Builddefinition verwendet wird, und deshalb sollte auch Ihren Arbeitsplatz Problem stoppen.

Answer 5

Ich konnte den Arbeitsbereich entfernen. Auf dem Build-Server dies tun:

Download psexec von Sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Öffnen cmd als Administrator an.

Ausführen psexec zu öffnen cmd als Network Service.
psexec -i -u "NT AUTHORITY \ Netzwerkdienst" cmd.exe Das öffnet ein weiteres Fenster cmd, dass „NT AUTHORITY \ Netzwerkdienst“ verwendet wird.

Führen Sie einen „whoami“, um sicherzustellen, dass Sie jetzt "NT AUTHORITY \ Netzwerkdienst".

Öffnen Sie Visual Studio durch Eingabe devenv.

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

Innerhalb Visual Studio \ Source-Control-Explorer, werfen die beanstandeten Workspaces entfernt.

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

Answer 6

Weitere Informationen über das Arbeitsverzeichnis Eigenschaft hier:

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

Doch in der RTM-Version "$ (homedrive)" wird nicht erkannt. Könnte sein, weil der Hülle; nicht getestet es so sein, bewusst, dass Fehler in der Dokumentation.

Answer 7

Ich hatte das gleiche Problem - es gut lief, bis ich VS2010 auf dem Build-Agenten installiert. Hinzufügen von Fest des BuildDefinitionId es, aber es ist seltsam, dass bis den Workspaces VS2010 Would Chaos installieren, die bereits eingerichtet sind und ausgeführt wird.

Answer 8

geändert zu

  

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

macht es funktioniert, aber nicht für 100% Situationen. Jedes Mal, wenn Build abgeschlossen ist (zB einige Fehler in der Quelle-Codes oder etwas) schlug fehl, dann nach Fehler Festsetzung und versuchen, Team Build laufen wieder schlägt es auf „Arbeitsbereich XYZ ist bereits vorgezeichnet ...“, dann muss ich diese manuell löschen Arbeitsplatz-Mapping von „Team Foundation Sidekick 2010“ und führte Team Build wieder Erfolg. Das nächste Mal gleiche Team bauen mehr als einmal die Ausführung erfolgreich gebaut, aber erst einige Team-Build nicht nach einiger Fehler im Quellcode, dann beginnen sie wieder auf „Arbeitsplatz-Mapping“ Fehler zu werfen.

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 Sie jemand gleichen Probleme haben?

Answer 9

==== ==== Visual Studio 2010

war ich nicht in der Lage, den „fehlerhaft“ Workspaces in TFS Handlanger, um zu sehen und damit sie nicht entfernen konnte. Die Schritte, die David Osborne wies mich in die richtige Richtung beschrieben. Ich war in der Lage, die „fehlerhafte“ Workspaces in TFS Handlanger zu sehen, und schließlich konnte ich sie entfernen.

On the build server do this:

Download psExec from sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Open cmd as Administrator.

Run psexec to open cmd as Network Service.
psexec -i -u "nt authority\network service" cmd.exe That opens another cmd window that "nt authority\network service" is using.

Run a “whoami” to make sure you’re now "nt authority\network service".

Open visual studio by typing C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.

When asked use the login from the TFS buildagent account to start Visual Studio.

Within visual studio\team explorer, Connect to the source control server

Within visual studio\ source control explorer, throw away the offending workspaces.

Delete the "faulty" workspaces with TFS SideKick.

Nun das Problem gelöst wurde.