2016-12-09 11 views
0

У меня следующие 2 ошибки при попытке построить на сервере сборки:Ошибка сборки Team Foundation Server. Не удалось скопировать «xxx.dll» в «yyy.dll»

путь \ to.NETFramework \ Microsoft.Common.targets (3390): Не удалось скопировать «путь \ в \ xxx.dll» в «путь \ to \ yyy.dll». Превышено количество попыток 10. Ошибка.

и

путь \ to.NETFramework \ Microsoft.Common.targets (3390): Не удается скопировать файл "путь \ к \ xxx.dll" на "путь \ к \ yyy.dll". Процесс не может получить доступ к файлу 'путь \ to \ yyy.dll', потому что он используется другим процессом.

Локально, это легко исправить - закрытие Visual Studio и запуск его в качестве администратора решает проблему. Однако при использовании сервера сборки (Microsoft Server) я не могу исправить эту проблему.

  1. Уже пытался перезагрузить агент сборки.
  2. Убедитесь, что мой проект был единственным зданием в то время.
  3. Вручную удалил dll.
  4. Запустите агент с аргументом /m:1.

Спасибо.

EDIT: Мне удалось воспроизвести ошибку локально. Если я изменю конфигурации в диспетчере конфигурации и очистку -> перестрою проект, это даст мне ту же ошибку. Однако, как я уже говорил, перезапуск VS решает эту ошибку, я просто не знаю, как это сделать на сервере.

+0

Убедитесь, что dll-файл не используется ни под каким процессом? Есть инструменты, которые вы можете использовать для проверки этого. – Mahdi

+0

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

+2

Вы можете удалить его вручную? – Mahdi

ответ

1

Наконец-то удалось найти решение. Оказывается, это не имеет ничего общего с самой TFS. Я не смог воспроизвести ошибку локально, потому что по какой-то причине она компилировалась, когда она не должна.

Моя проблема была "broken links". Я использую некоторые Biztalk и 5 из них имели зависимость от другого проекта (изготовленный на заказ Biztalk Компоненты трубопровода), но не ссылка на сам проект. Я думаю, что это может быть вызвано открытием инструментария компонентов, хотя я не уверен в этом.

Итак, я вручную удалил и добавил ссылки (Add-> Reference) в указанные проекты, и теперь все работает как шарм.

1

Если вы используете XAML сборки вы могли бы попытаться решить эту проблему с помощью установки отключить параллельную сборку в сборке server.For TFS2010 и TFS2012 настройки MSBuild Multi-Proc на вкладке Process в Ложный, для TFS2013, TFS2015 типа /m:1 в MSBuild Аргументы. Для получения дополнительной информации о аргументе/m в MSBuild обратитесь к этому документу: MSBuild Command-Line Reference

Переключение на отдельные сборки процессов увеличило время сборки, но если это приемлемая потеря. Вы можете использовать это как обходной путь.

+0

Я использую TFS2015. Пробовал аргумент '/ m: 1', но не работал. Знать любое другое возможное решение? –

+0

Могли бы вы вручную создать агента успешно? –

+0

Я установил Агента для запуска MSBuild в x86. Это должно быть так, потому что некоторые проекты, которые я только запускал в x86. Однако есть и другие, и другие могут работать в x64. Я думаю, что проблема может быть в этом. –

 Смежные вопросы

  • Нет связанных вопросов^_^