Błąd kompilacji zespołu: ścieżka… jest już zmapowana do obszaru roboczego

Podczas tworzenia nowej kompilacji w Team Foundation Server podczas próby uruchomienia nowej kompilacji pojawia się następujący błąd:

Ścieżka C: \ Build \ ProductReleases \ FullBuildv5.4.2x \ Sources jest już zamapowana na obszar roboczy BuildServer_23.

Nie widzę obszaru roboczego o tej nazwie w oknie dialogowym obszarów roboczych.

Użyj narzędzia wiersza poleceń TF - Team Foundation Version Control Tool ( tf ).

Możesz uzyskać listę wszystkich obszarów roboczych, wywołując wiersz polecenia programu Visual Studio, a następnie przechodząc do folderu obszaru roboczego i wydając następujące polecenia:

C:\YourWorkspaceFolder>tf workspaces /owner:*

Na liście powinien być widoczny obszar roboczy, w którym występuje problem, oraz jego właściciel.

Możesz usunąć obszar roboczy za pomocą następującego polecenia:

C:\YourWorkspaceFolder>tf workspace /delete /server:BUILDSERVER WORKSPACENAME;OWNERNAME

Po prostu usuń zawartość następujących folderów:

C: \ Users \ UserName \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache

Gdzie nazwa_użytkownika to rzeczywisty lub bieżący użytkownik, a 3.0 to numer wersji.

Otrzymałem ten błąd, który był spowodowany posiadaniem dwóch definicji kompilacji wskazujących na to samo źródło. Problem polegał na tym, że użyłem statycznego katalogu kompilacji w programie Build Agent.

Ten post na forum dokładnie opisuje mój problem i jego rozwiązanie: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

Miałem podobny problem i aby usunąć obszar roboczy, który sprawiał mi problem, zalogowałem się na innym komputerze z zainstalowanym klientem TFS i wykonałem następujące czynności:

• Na pliku menu, wskaż Kontrola źródła , Zaawansowane , a następnie kliknij obszarów roboczych ... .
• W oknie dialogowym Zarządzaj obszarami roboczymi zaznacz pole wyboru Pokaż pakiety zdalne .
• W kolumnie Nazwa wybierz obszar roboczy, który chcesz usunąć, a następnie kliknij przycisk Usuń .
• W oknie dialogowym Potwierdzenie kliknij OK .

Mieliśmy ten sam problem, ale usunięcie obszaru roboczego z serwera TFS nie działało. (Powinienem wspomnieć, że złapałem maszynę wirtualną moich kolegów, która była już skonfigurowana z jego poświadczeniami.)

U mnie to zadziałało: http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx

Właśnie wszedłem do: ... \ Ustawienia lokalne \ Dane aplikacji \ wyszukałem VersionControl.config, otworzyłem folder zawierający ten plik i usunąłem całą jego zawartość.

Wcześniej próbowałem ręcznie edytować plik, ale kontynuowałem z tym samym komunikatem o błędzie.

Mam nadzieję, że to pomoże.

Z jakiegoś powodu miałem problem z usunięciem obszaru roboczego z narzędzia wiersza poleceń. Na szczęście znalazłem Team Foundation Sidekicks 2010 (z tego postu ), która jest bezpłatna i zapewnia GUI do przeglądania i usuwania obszarów roboczych TFS oraz wiele innych przydatnych funkcji TFS.

Miałem podobny problem z Visual Studio 2010 narzekającym na już zmapowany obszar roboczy, ale zamiast usuwać cały obszar roboczy, użyłem następującego polecenia z wiersza polecenia programu Visual Studio: „tf workspace PROBLEM_WORKSPACE_NAME”. Spowoduje to wyświetlenie okna dialogowego „Edytuj obszar roboczy”. Stamtąd mogłem usunąć omawianą ścieżkę z listy „Foldery robocze”, co pozbyło się błędu.

reszta była dość łatwa.

Po prostu przejdź do tego folderu: C: \ Users {nazwa_użytkownika} \ AppData \ Local \ Microsoft \ Team Foundation \ 4 \ Cache i usuń wszystko, co znajduje się w folderze.

Otrzymałem wyjątek informujący mnie, że plik został już zmapowany w innym obszarze roboczym: „Ścieżka {ścieżka pliku} jest już zamapowana w obszarze roboczym {nazwa obszaru roboczego}”.

Ten obszar roboczy został usunięty wcześniej . Z pomocą znajomego dowiedziałem się, że TFS zapisuje informacje o obszarze roboczym w katalogu ustawień lokalnych użytkownika. Znaleźliśmy plik o nazwie:

VersionControl.config w katalogu {User Documents and Settings dir} \ Local Settings \ Application Data \ Microsoft \ Team Foundation \ 1.0 \ Cache. Ten plik zawiera całe lokalne mapowanie TFS. Prawdopodobnie gdy używasz metody Map i nie używasz: public void DeleteMapping (mapowanie WorkingFolder); przed usunięciem obszaru roboczego informacje o mapowaniu nie są usuwane z tego pliku, który jest używany przez TFS do sprawdzania, czy została już zmapowana określona ścieżka.

Aby rozwiązać ten problem, usuń wszystkie klucze z pliku konfiguracyjnego. Nie usuwaj pliku, ponieważ otrzymasz go ponownie z pamięci podręcznej serwera.

Oto, co zrobiłem (cóż, co robię):

Korzystanie z TFS Sidekicks powoduje wyczyszczenie filtrów użytkowników i serwerów, dzięki czemu są one puste. Umożliwi to uzyskanie wszystkich obszarów roboczych.

Sprawdź błąd kompilacji dla nazwy obszaru roboczego. W przypadku OP jest to BuildServer_23. W moim środowisku jest inaczej, ale po prostu dopasuj nazwę błędu do nazwy z listy pomocników tfs.

Kliknij czerwony znak x, aby usunąć obszar roboczy.

Altówka!

Jeśli nie masz uprawnień na serwerze do usuwania obszarów roboczych innych osób, możesz po prostu zmienić nazwę definicji kompilacji. TFS utworzy nowy obszar roboczy i zamapuje go na „C: \ Build \ ProductReleases \ nowa nazwa kompilacji tutaj \ Sources”.

Jeśli ma to zastosowanie, możesz również sklonować definicję kompilacji i zmienić jej nazwę. To zadziałało dla mnie.

Wypróbowałem wszystkie poniższe rozwiązania, takie jak:

1. Użyj pomocników, aby usunąć WS.
2. Użyj poleceń tf, aby usunąć obszary robocze serwera zdalnego.
3. Usuń folder pamięci podręcznej TFS.

Pracowały dla mnie:

tf workspaces /remove:*

Zmieniłam

Build Definition -> Workspace -> Build Agent Folder

z

c:\some\path

do

$(SourceDir)

i rozwiązało problem.

Podczas próby „Pobierz najnowszą wersję” projektu, który wcześniej zmapowałem do katalogu lokalnego, a następnie usunąłem, zobaczyłem ten sam komunikat o błędzie. Najpierw wypróbowałem narzędzie SideKick, a następnie wiersz polecenia programu Visual Studio 2010, które poinformowały mnie, że nie mam zmapowanych obszarów roboczych.

Następnie wyszukałem „VersionControl.config” w obrębie c:/users/myuser/appdatai usunąłem 4 znalezione odniesienia. Ponownie otworzyłem Visual Studio i mogłem ponownie zmapować projekt, koniec z błędami!

Najprostszym sposobem na to jest przejście do AppData i usunięcie pamięci podręcznej TFS (w zależności od wersji 3.0 lub 4.0)

C: \ Users {nazwa użytkownika} \ AppData \ Local \ Microsoft \ Team Foundation \ 3.0 \ Cache lub C: \ Users {nazwa_użytkownika} \ AppData \ Local \ Microsoft \ Team Foundation \ 4.0 \ Cache

Rozwiązanie TDN działało dla mnie, gdy miałem ten sam problem. Serwer kompilacji utworzył obszary robocze na moim koncie. Zaznaczenie tego pola pozwoliło mi je zobaczyć i usunąć.

Mam ten sam problem w Visual Studio 2017 i TFS 2017. DefaultCollection musi być najpierw zamapowany na ścieżkę lokalną. W jakiś sposób ten krok został pominięty i zmapowany został tylko MyFirstProject.

Wszystko, co musisz zrobić, to:
- 1. Przejdź do strony WWW TFS i usuń projekt z serwera.

- 2. Usuń projekt z lokalnego „Worksapces”

- 3. Przejdź do „Zarządzaj połączeniami”, co spowoduje odświeżenie strony głównej w TeamExplorer.

- 4. Pojawi się strona Konfiguracja, która pozwoli Ci ustawić ścieżkę główną do kolekcji DefaultCollection.

- 5. Powinien pojawić się komunikat, że wszystko się udało. Teraz możesz stworzyć swój projekt.

Ważne jest, aby najpierw zamapować katalog główny swojej kolekcji na obszar roboczy, a następnie zmapować nowy projekt.

Mój problem był związany z używaniem wielu kont. W ten sposób mogłem przełączać konta.

Otwórz Team Explorer

Z dużego menu rozwijanego u góry panelu ...

Przejdź do: Projekty i moje zespoły > Zarządzaj połączeniami

Przejdź do: Zarządzaj połączeniami > Połącz z projektem zespołowym

Użyj linku „Przełącz użytkownika”, aby przełączyć konto.

Teraz nazwy obszarów roboczych będą pasować do wybranego konta.

Nie mogłem znaleźć innego rozwiązania do pracy.

Utworzono nowe konto, a stare konto nie miało już uprawnień (oba na tym samym komputerze).

Próbowałem: 1) Usuwanie obszaru roboczego (nie widziałem w VS z zaznaczonymi zdalnymi obszarami roboczymi lub bez) 2) Usuwanie z wiersza poleceń 3) Nowe polecenie właściciela 4) Usuwanie pamięci podręcznej

Więc po prostu otworzyłem VS jako administrator i zmapowałem do innego folderu.

Miałem ten problem z automatycznymi kompilacjami usługi Azure DevOps w lokalnym agencie kompilacji TFS. Usunięcie obszaru roboczego za pomocą TFS Sidekicks nie działa. A tf.exe nie mógł nawet znaleźć obszaru roboczego, aby go usunąć.

To rozwiązanie powinno działać w przypadku TFS 2017, TFS 2018, Azure DevOps i prawdopodobnie innych wersji:

1. Zwróć uwagę na identyfikator GUID obszaru roboczego w komunikacie o błędzie.
2. Na komputerze, na którym odbywa się kompilacja, przejdź do:% USERPROFILE% \ AppData \ Local \ Microsoft \ Team Foundation \ (gdzie% USERPROFILE% należy do użytkownika, który wyzwolił kompilację).
3. Wyszukaj i usuń wszystkie wystąpienia identyfikatora GUID obszaru roboczego w tym katalogu. Prawdopodobnie w katalogu „cache” będzie znajdować się folder, a także wpisy w „LocationServerMap.xml” i „LocalItemExclusion.config”. Usuń je wszystkie.

To zadziałało w moich okolicznościach.

Po prostu usuń obszar roboczy:

workspace /delete "the-workspace-name"