MSBuild перезаписывает зависимости

Question

Хорошо, у меня есть несколько сложная проблема с моей средой сборки, с которой я пытаюсь разобраться.

У меня есть файл решения, который содержит несколько проектов на C #, который создается с помощью сценария NAnt с именем MSBuild, в котором MSBuild передается имя файла решения и путь для копирования двоичных файлов. Это потому, что я хочу, чтобы моя автоматизированная среда сборки (CruiseControl.Net) создала папку, названную после ревизии каждой сборки, - так я могу легко вернуться к предыдущим двоичным файлам по любой причине.

Так что в идеале у меня есть макет папки, как это

c:\build\nightly\rev1
c:\build\nightly\rev2
c:\build\nightly\rev3
...
c:\build\nightly\rev10
etc.

Возникшая проблема заключается в том, что я недавно добавил последнюю версию контейнера Unity IoC в свой проект, проверив ее непосредственно из онлайн-хранилища SVN от MS. Происходит то, что у меня есть проект Silverlight 3, который ссылается на версию Unity Silverlight, но у меня также есть другие проекты (а именно мой проект модульного тестирования), которые ссылаются на стандартную (не Silverlight) версию Unity.

Так что происходит, так как MSBuild сбрасывает все в одну папку, Версия сборки Unity для Silverlight перезаписывает версию, отличную от Silverlight, поскольку они имеют одинаковое имя файла сборки .

Затем, когда CruistControl запускает мои модульные тесты, они терпят неудачу, потому что у них больше нет соответствующих зависимостей (они пытаются загрузить определенную сборку Silverlight Unity, которая, очевидно, не работает).

Итак, что я хочу сделать:

• сохранить мой желаемый выходной каталог структура (папка \ ревизия)
• Я не хочу редактировать вручную каждый файл proj у меня есть, как это подвержен ошибкам при добавлении нового проекты к решению

В идеале я бы хотел, чтобы MSBuild поместил все в структуру папок, подобную этой:

nightly\revision1\project1
nightly\revision1\project2
nightly\revision1\project3
...
nightly\revision2\project1
nightly\revision2\project2
nightly\revision2\project3
etc

Я не могу изменить проект Unity, чтобы дать ему другое имя файла, потому что он взят из другого репозитория SVN, в который я не могу зафиксировать изменения. Я нашел похожий вопрос, размещенный здесь, и предложенное решение состояло в том, чтобы использовать «главный» файл MSBuild, который использовал пользовательскую задачу для извлечения всех имен файлов проекта из решения, а затем перебрать каждый из них, создавая их. Я попробовал это, но он не строит их в порядке их зависимостей, поэтому он не работает для моего проекта.

Помощь

Answer 1

Для сторонних библиотек я бы просто включил каталог DLLs в ваш репозиторий. Нет ничего хуже, чем написание какого-либо кода и наличие сторонней зависимости нарушают вашу сборку из-за изменений в их конце.

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

Кроме того, разве CC.Net не выполняет автоматическую обработку выпусков на основе версий? Я использую TeamCity, и он хранит копии артефактов каждой сборки.

Я настоятельно рекомендую прочитать Автоматизированные сборки JP Boodhoo с серией блогов NAnt . Это было моей отправной точкой, и я сделал много изменений на свой вкус. Я также настоятельно рекомендую проверить сборки многих проектов с открытым исходным кодом для примеров. Я многому научился из сборок стека Castle / Nhibernate / Rhino-Tools.

Answer 2

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

Далее я бы использовал nant или msbuild для сборки решений, как и раньше, с артефактами из каждой сборки, направляющимися в их локальные рабочие выходные папки.

После этого я бы переместил артефакты из их рабочих путей в их выходные пути, для этого не нужно копаться в файлах проекта, поскольку вы можете просто указать msbuild / nant скопировать working\project1\bin\release\**\*.* в artifacts\project1\.

Сценарий, который делает это, в идеале должен храниться вместе с источником вместе с основным файлом, например build.nant или build.proj на верхнем уровне транка.