Периодически происходит сбой сборки веб-сайта 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

Поиск в 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.Итак, мы добавили задачу перезапускать сервис Hudson каждое утро в 6 утра. Даже с этим и разумным объемом доступной памяти, готовой к работе во время сборки, все равно не получилось.
• Отправка в тот же репозиторий также приводит к одновременной сборке гораздо более простого (всего 22 проекта, без проектов веб-сайта) решения. Это всегда удается. Кроме того, вручную запустить их оба для запуска в одно и то же время удается.
• Я знаю, что мы должны обновить Hudson, но это всегда один из тех второстепенных проектов, на которые у нас никогда не хватает времени. В любом случае, я довольно сильно чувствую, что это проблема Visual Studio/MSBuild, а не проблема Хадсона.

Редактировать 1: MSBuild

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

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