Отсутствие зависимостей при построении через CruiseControl

Question

Проблема в том, что когда проекты создаются и производятся нормально без каких-либо ошибок, в окончательном пакете MSI отсутствуют сборки зависимостей, которые обычно упаковываются, если кто-то, например, создает проект с помощью Visual Studio. Так что получается, что приложение устанавливается нормально, а затем падает во время выполнения, говоря, что отсутствует xyz dll.

Из того, что я могу сказать, он либо не обновляет зависимости перед сборкой проекта установки, либо каким-то образом не включает их все.

Мы строим с использованием devenv и файла решения (Перестроить все)

Кто-нибудь сталкивался с чем-то подобным, и если да, то как вы решили это?

edit: CruiseControl работает в другой обработке, чем в разработке. Более того, мы выяснили, что это происходит с проектами, на которые есть ссылки в решении.

IE в решении с 3 проектами: A - библиотека, B - приложение, которое ссылается на A и C - проект установки, а затем после сборки получается, что B отсутствует A, хотя сборка прошла успешно, а msi произвела.

Answer 1

Эта ситуация является результатом того, что MSBUILD не поддерживает проекты установки. Поэтому мы вынуждены использовать devenv для создания решения с помощью круиз-контроля.

Реальная проблема заключалась в том, что основное приложение ссылалось на проекты в одном и том же решении, и хотя это не воспроизводилось в проектах полной установки .NET, это неоднократно происходило в проектах установки CF.

Мы решили эту проблему, изменив архитектуру наших CF-решений, чтобы все связанные проекты в 1 проекте были в виде папок, поэтому в проекте установки был создан и упакован только 1 exe.

Примечательно, что у нас не было пропущенных сборок при обращении к другим файлам dll, но только когда мы обращались к проектам библиотек, которые существовали в том же решении.

После поиска в этой теме я обнаружил некоторые тревожные подробности об этой теме, которые указывают мне на тот факт, что эта ошибка и неспособность msbuild поддерживать проект установки существуют с ~ 2005 года в отчетах форума msdn и не только.

Answer 2

Когда вы говорите, что он прекрасно работает через Visual Studio вручную, вы имеете в виду на той же машине? Если это так, то это, вероятно, тот факт, что ваша служба cruisecontrol запущена от имени другого пользователя, и поэтому в ней установлены разные пути и переменные среды, возможно, у нее нет прав доступа к файловой системе, на которой эти зависимости включены. Если вы имеете в виду, что он отлично работает на другой машине, то я бы позаботился о том, чтобы эти зависимости действительно присутствовали и чтобы пользователь, которому запускается служба, имел права доступа к ним. Мы никогда не сталкивались с этими проблемами, извините, поэтому я просто пытаюсь угадать несколько потенциальных проблем с CC.NET.

Answer 3

Вы можете проверить, есть ли отсутствующие dll в GAC на компьютере сборки.

Несколько месяцев назад я столкнулся с проблемой, когда сборочный сервер генерировал установку с наименьшим количеством dll, чем любой из блоков разработчика. Оказывается, отсутствующая DLL была в GAC на коробке сборки. По какой-то неизвестной причине VS2005 решил, что не нужно включать dll, поскольку он был в GAC - даже если мы специально ссылались на локальную копию dll в проекте.

Answer 4

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

https://stackoverflow.com/questions/45593?sort=votes#sort-top