У меня есть решение, которое содержит проекты C ++ и C #, встроенные в ночную сборку CI на удаленном компьютере. Сценарий сборки проверяет чистую копию источника и создает конфигурации отладки и выпуска решения с помощью MSBuild и запускает набор тестов для каждой конфигурации.
Что касается каждой второй сборки, конфигурация выпуска не может быть правильно построена. Анализ журнала сборки показывает, что C ++ Project Q, который зависит от C ++ Project D, пытается установить связь до завершения Project D. Эта ошибка возникает только для конфигурации выпуска на этом конкретном компьютере сборки - конфигурация отладки строится без ошибок. У меня есть отдельный процесс ночной сборки, который выполняется на отдельном компьютере, где конфигурация выпуска создается с помощью аналогичного сценария, который использует MSBuild (он просто не запускает набор тестов), и он без проблем создает ту же исходную ревизию. Несколько членов команды создают решение без проблем с помощью обновления или чистой проверки с одной или обеими конфигурациями, всегда из среды разработки Visual Studio 2019, в различных операционных системах.
Project Q настроен с использованием Project D в качестве ссылки на проект, а Project D также указан как жесткая зависимость для Project Q. Как я уже упоминал, сценарий сборки использует MSBuild.
Дополнительный интересный момент из анализа журналов сборки выпуска и отладки: сборка Project D запускается по-разному между двумя сборками конфигурации. Он запускается собственным метапроектом в конфигурации выпуска (например, как элемент 60), но запускается раньше (например, как элемент 44) другим проектом в конфигурации отладки. Не уверен, почему алгоритм зависимости будет работать с такими разными результатами в двух случаях, поскольку создаваемое решение и рабочий источник одинаковы.
Любые идеи или предложения будут оценены.
Обновление. Проверка различий между журналами выпуска и отладочной сборки позволяет выявить некоторые интересные факты. В случае сбоя я выполнил поиск «) строится» в каждом журнале - должно быть указание на то, сколько проектов было построено, включая записи метапроекта. Для случая сбоя отладка имела 282 вхождения, тогда как выпуск - 175. В случае успеха отладка имела 280 вхождений, а выпуск - колоссальные 559! Подобный поиск по запросу «Готовый проект строительства» дает аналогичные результаты, только с точностью до 1 или 2. Это может частично объяснить различия в порядке сборки между решениями. Мне также нужно проверить записи условной сборки.
