Ссылка на один и тот же проект в двух решениях приводит к сбою построения второго решения

Question

Я получаю сообщение об ошибке при сборке сложного проекта на сервере сборки TFS.Я смог воспроизвести ошибку с более простой настройкой, которую я буду использовать здесь для описания проблемы.Из-за возраста и сложности проект все еще использует инструменты сборки Visual Studio 2010.

У меня есть хранилище с двумя решениями: WindowsProject1 и WindowsProject2, которые оба являются приложениями MFC.Я также добавил проект WindowsProjectTools к обоим решениям, потому что на DLL ссылается основной проект в обоих.

Проблема возникает при построении решений на сервере сборки следующим образом:

Первый шаг сборки (WindowsProject1) выполнен успешно, но второй (WindowsProject2) завершается неудачно со следующими ошибками:

Error C1090: PDB API call failed, error code '23' : '(

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

Я подозревал, что сборка WindowsProjectTools на обоих этапах сборки по какой-то причине будет конфликтовать, возможно, промежуточная папка пересекается, поэтому я изменилэто $ (SolutionDir) $ (конфигурация) \, но это не помогло.

Однако изменение порядка шагов сборки помогает, поскольку тогда сборка WindowsProject2 завершается успешно, а WindowsProject1 завершается неудачей.Это заставляет меня поверить, что файлы решения и проекта в порядке, но в TFS есть некоторые параметры, которые мне не хватает.

Я также пытался изменить версию MSBuild с Последней версии на 4.0 (версии, связанной сVS2010) безуспешно.

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

Answer 1

Я обнаружил сообщение об ошибке по большей части похожей проблемы на сервере сборки Jenkins: https://issues.jenkins -ci.org / browse / JENKINS-9104

Программа mspdbsrv.exe кажетсяне подходит для параллельных сборок.Обходной путь для Дженкинса состоял в том, чтобы изменить временный каталог:

_MSPDBSRV_ENDPOINT_=<UUID>
TMP=<Unique Tempdir>
TEMP=$TMP TMPDIR=$TMP

В другом решении mspdbsrv поддерживался в течение всего процесса сборки:

rem :: PITA to keep MSPDBSRV alive
set ORIG_BUILD_ID=%BUILD_ID%
set BUILD_ID=DoNotKillMe
start mspdbsrv -start -spawn
set BUILD_ID=%ORIG_BUILD_ID%
set ORIG_BUILD_ID=

(сначала PITA поставил меня в тупик,никогда не слышал об этом, что это за новая технология !? Тогда я посмеялся.)

Ни то, ни другое нам не помогло.В последнем случае сервер сборки только что запустил другой экземпляр mspdbsrv.exe.Мы догадались, что сервер запускается каждый раз, когда создается новое решение.Поскольку между этапами сборки мало времени (1/10 секунды), мы предположили, что серверная программа не готова к перезапуску так скоро после своего выхода.Обход, который мы сейчас реализовали, - это шаг сборки сценария powershell между шагами сборки решения, который ждет 10 секунд до продолжения:

Start-Sleep -Seconds 10

Это дает mspdbsrv.exe достаточно времени для завершения работы и перезапуска.Ошибка pdb api больше не возникает.

Я понимаю, что это просто еще один обходной путь, но мы не можем позволить себе тратить на это больше времени.Нашей главной заботой было то, что наши сборочные артефакты не повреждены и находятся в надлежащем виде, чего не было с другими решениями (такими как / Z7 вместо / Zi).Таким образом, наш обходной путь превосходен.

В других ситуациях, провоцирующих вызов API PDB, произошел сбой, код ошибки «23» может быть не решен с помощью этого обходного пути, но я рекомендую рассмотреть поведение mspdbsrv.exe.