Сборка команды: путь «Путь» уже отображается в ошибке «Рабочая область» рабочей области даже после удаления всех рабочих областей в агенте сборки - PullRequest
24 голосов
/ 24 февраля 2010

У меня есть эта проблема, когда я ставлю в очередь сборку. Сборка умирает с ошибкой

Путь C: \ [Path] \ Sources уже сопоставлен в рабочей области [Имя сервера].

такой же, как этот вопрос . но я удалил все рабочие области в агенте сборки, выполнив эту команду:

tf workspaces /remove:*

, а также путем удаления папки кэша TFS. Я также перезапустил сервер, но ошибка продолжает происходить при каждой сборке.

Ответы [ 9 ]

20 голосов
/ 26 февраля 2010

Хорошо, так что решение оказалось довольно похожим на то, что YeahStu опубликовал здесь .Я изменил рабочий каталог агента сборки с

$(Temp)\UI\$(BuildDefinitionPath)

на

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

Странно то, что другой имеющийся у нас агент сборки все еще работает в $(Temp)\UI\$(BuildDefinitionPath) и работает нормально.Единственное различие между этими двумя агентами состоит в том, что на том, который прекратил работать, была установлена ​​Visual Studio 2010 RC, а на том, который все еще работает, на нем установлена ​​бета-версия VS2010.Не знаю, почему это должно иметь значение.

4 голосов
/ 02 апреля 2012

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

Ну, на самом деле эта проблема была решена в нескольких других вопросах на этом сайте, но я снова выложу свой ответ:)

Эта ссылка направит вас в блог, который, вероятно, решит вашу проблему быстрее всего

3 голосов
/ 13 января 2011

Я думаю, что проблема появляется, только если у вас есть более одного агента сборки на одной коробке сборки.

1 голос
/ 27 марта 2015

Мне удалось удалить рабочее пространство. На сервере сборки сделайте это:

Скачать psExec от sysinternals.
http://technet.microsoft.com/en-us/sysinternals/bb897553

Открыть cmd от имени администратора.

Запустите psexec, чтобы открыть cmd в качестве сетевой службы.
psexec -i -u "nt полномочия \ сетевая служба" cmd.exe Это открывает другое окно cmd, которое использует "nt полномочия \ сетевая служба".

Запустите «whoami», чтобы убедиться, что вы теперь «nt полномочия \ сетевая служба».

Откройте визуальную студию, набрав devenv.

В Visual Studio \ Team Explorer, Соединитесь с сервером контроля версий

В Visual Studio \ Source Control Explorer, выбросить оскорбительные рабочие пространства.

Понятия не имею почему, но рабочие области tf / remove не работали для меня.

1 голос
/ 13 апреля 2011

Я думаю, что ваша проблема, возможно, связана с наличием 3 агентов сборки, которые не помечены. Я думаю, что рабочее пространство, если оно осталось позади, удаляется агентом, который выполняет сборку. Если это агент, отличный от агента, который создал рабочую область, тогда будут очевидные проблемы.

Итак, чтобы решить проблему, вам нужно сделать следующее. Назовите одного агента агентом по умолчанию. Это будет не теги. В двух других агентах в свойствах добавьте тег для агентов, по одному для каждого агента, и выберите его.

Теперь любая выполняемая сборка без установленного тега всегда будет использовать Агент по умолчанию.

Чтобы заставить сборку использовать один из других агентов, откройте определение сборки и перейдите в расширенный раздел Process.

Откройте настройки агента и выберите многоточие в фильтре тегов и введите тег с тем же именем для тега, введенного в агент построения, который вы хотите использовать.

Может потребоваться очистить рабочие пространства перед первым запуском.

Выполнение вышеописанного позволяет вам контролировать, какой агент сборки используется для каждого определения сборки, и, следовательно, также должно остановить проблему вашего рабочего пространства.

0 голосов
/ 16 ноября 2018

==== Visual Studio 2010 ====

Я не смог увидеть «неисправные» рабочие пространства в TFS Sidekick и, следовательно, не смог их удалить. Шаги, которые описал Дэвид Осборн, указали мне правильное направление. Я смог увидеть «неисправные» рабочие пространства в TFS Sidekick и, наконец, я смог их удалить.

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.

Теперь проблема решена.

0 голосов
/ 13 января 2011

Изменено на

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

делает это работающим, но не для 100% ситуаций. Каждый раз, когда сборка не завершалась (например, какая-то ошибка в исходных кодах или что-то в этом роде), после исправления ошибки и повторной попытки сборки команды он завершается с ошибкой «Рабочая область XYZ уже сопоставлена ​​...», затем я должен вручную удалить это сопоставление рабочего пространства с помощью Team Foundation Sidekick 2010 и повторное создание команды для достижения успеха. В следующий раз выполнение одной и той же групповой сборки более одного раза будет успешно выполнено, но до тех пор, пока сборка какой-либо команды не завершится с ошибкой из-за некоторой ошибки в исходном коде, она снова начнет выдавать ошибки «отображение рабочего пространства».

Мне кажется, что в TFS 2010 есть какая-то ошибка, когда не удается собрать какую-либо команду, не очищает / удаляет используемое рабочее пространство или что-то подобное.

У кого-то такие же проблемы возникают?

0 голосов
/ 18 мая 2010

У меня была такая же проблема - она ​​работала нормально, пока я не установил VS2010 на агенте сборки. Добавление BuildDefinitionId исправило это, но странно, что установка VS2010 испортит рабочие пространства, которые уже настроены и работают.

0 голосов
/ 29 апреля 2010

Подробнее о свойствах рабочего каталога здесь:

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

Однако в RTM-версии "$ (HOMEDRIVE)" не распознается. Может быть из-за корпуса; еще не проверял, так что помните об этом недостатке в документах.

...