Создание веб-сайта Visual Studio прерывается с ошибкой на сервере CI

У нас есть довольно сложное решение Visual Studio (57 проектов, из которых 19 - это сайт, который не удается построить почти каждый раз, когда запускается путем нажатия кода, но затем мы вручную запускаем сборку, а на повторном запуске строит ее просто отлично.

Решение содержит 57 проектов, из которых 19 - проекты веб-сайтов. (Не проекты веб-приложений, файл .csproj отсутствует.) Остальные - библиотеки классов и фоновые задания. 19 проектов веб-сайтов структурированы в виртуальных каталогах IIS в одну большую многофункциональную систему управления контентом.

Сервер сборки - Hudson v1.395. Команда, которая используется для сборки:

"C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com" "SolutionName.sln" /rebuild Debug

Когда сборка завершается с ошибкой, она всегда делает это на одном и том же проекте веб-сайта с тем же сообщением:

------ Rebuild All started: Project: C:\...\WebsiteName\, Configuration: Debug Any CPU ------
Validating Web Site
: Build (web): The application domain in which the thread was running has been unloaded.

Validation Complete

A Поиск Google для этого сообщения в настоящее время менее полезен. Эта ссылка наиболее близка к актуальной проблеме, но не имеет разрешения. Очевидно, что мы не меняем файлы решений во время сборки, потому что это происходит на сервере сборки.

Когда он терпит неудачу, мы запускаем сборку вручную, и получаем то, что ожидаем (извините, отредактировано):

------ Rebuild All started: Project: C:\...\News2\, Configuration: Debug Any CPU ------
Validating Web Site
Building directory '/WebsiteName/Dir1/Dir2/'.
Building directory '/WebsiteName/'.
Building directory '/WebsiteName/Dir3/'.
// 22 more but you get the point

// A few warnings caused by our own use of the ObsoleteAttribute, nothing to be concerned about
Validation Complete

Что может привести к выгрузке этого сообщения для домена приложения?

Некоторые другие примечания:

Мы думали, что у Хадсона может быть нехватка памяти, потому что мы наблюдаем, как java сильно просачивается. Итак, мы добавили задачу перезапуска службы Хадсона каждое утро в 6 утра. Даже с этим и разумным количеством доступной памяти, готовой к работе во время сборки, все равно не удалось.
Нажатие на тот же репозиторий также приводит к созданию гораздо более простого (всего 22 проекта, без проектов веб-сайтов) в одно и то же время. Это всегда удается. Кроме того, вручную запускается их запуск обоих одновременно.
Я знаю, что мы должны обновить Хадсона, но это всегда один из тех проектов backburner, на которые мы, похоже, никогда не успевали. В любом случае, я довольно уверен, что это проблема Visual Studio/MSBuild, а не проблема Хадсона.

Изменить 1: MSBuild

Проблема с MSBuild заключается в том, что существует так много небольших причуд, которые отличаются от сборки в Visual Studio. Это очень сложно для решения компиляции в Visual Studio на машине разработчика, а затем сбой на сервере сборки. Даже вывод из msbuild резко отличается (гораздо более подробным для одной вещи) от того, что наши разработчики видят в окне вывода сборки. Существуют ли дополнительные флаги командной строки, которые выводят вывод MSBuild в соответствие с тем, что вы получаете в окне сборки Visual Studio?

Есть и другие вещи, которые неудобны. Если у вас есть папка с решением так же, как и проект, MSBuild выдает ошибку, но Visual Studio справляется с ней просто отлично. Это причуды, которые действительно заставляют вас вытаскивать волосы.

Ответ 1

У меня возникла проблема с сборками С++ на Hudson/Jenkins, которые, вероятно, связаны, если у вас сразу две сборки, тогда могут произойти плохие вещи.

Это связано с тем, что Hudson/Jenkins запускает обработчик дерева процессов для очистки процессов в конце сборки, а MsBuild/VisualStudio будет совместно использовать некоторые общие процессы между сборками.

Фактическая проблема, с которой я столкнулась с С++-сборками, проявила себя как еще одна ошибка:

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

Вопрос был поднят здесь:

https://issues.jenkins-ci.org/browse/JENKINS-9104

Отключение обработчика дерева процессов может решить вашу проблему.

Ответ 2

Я не знаком с Хадсоном или проектом веб-сайта (я использую проекты TeamCity и веб-приложений), но я решил, что брошу пару вещей, чтобы посмотреть, поможет ли это.

Вы пытались создать решение с помощью MSBuild напрямую, а не с помощью Visual Studio? Команда будет выглядеть примерно так:

    %windir%\Microsoft.NET\Framework\<version>\MSBuild SolutionName.sln /t:Rebuild /p:configuration=debug

Я заметил, что вы не передавали переключатель командной строки в visual studio для закрытия после завершения сборки /RunExit MSDN Link Так что что Visual Studio IDE открывается на вашем сервере сборки для каждой сборки и не закрывается? Я мог видеть, что несколько экземпляров IDE, имеющих одно и то же решение, вызывают проблемы.

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

Надеюсь на эту помощь!

Ответ 3

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

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

Я предполагаю, что если вы вообще не подозревали об этом, вы бы не упоминали об этом в своем посте. Измените это.