У нас есть довольно сложное решение 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 справляется с ней просто отлично. Это причуды, которые действительно заставляют вас вытаскивать волосы.