Выход одной сборки включен в другую

Question

Как правильно включить вывод одной сборки в виде двоичного файла в другую сборку?

Допустим, у меня есть решение под названием CompanyName.Domain (мой уровень домена). Я настроил его как сборку, и он собирается ночью.

Теперь я хочу добавить решение под названием SomeProject.Web. И я хочу включить двоичный файл из CompanyName.Domin в папку Binaries на одном уровне с моим решением. Тогда будет работать проект SomeProjects.Web со ссылкой на Binaries \ CompanyName.Domain.dll.

Что такое лучшие практики для этого? Я знаю кого-то, кто сказал, что они пытались сделать это с помощью ветвления. Я полный "источник контроля" новичок. Но что-то в этом звучит неправильно.

Answer 1

Так же, как Дэрил, мы используем папку «Binaries», из которой мы ссылаемся на двоичные файлы. Наши «библиотеки» просто копируют результаты в расположение двоичных файлов, поэтому, если мы хотим обновить библиотеки, мы просто проверяем двоичные файлы, собираем и регистрируем их снова.

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

Будьте осторожны, чтобы ссылаться только на сборки Release ваших библиотек (единственное исключение, которое у нас есть, это то, что у нас есть библиотека помощников по отладке, которые условно компилируются только в отладочные сборки, и мы должны ссылаться на отладочную версию этого, в противном случае все наша отладка компилируется из программы даже в отладочных сборках!)

Последнее замечание: избегайте ветвления, если нет разумной альтернативы.

Answer 2

Мой процесс похож на процесс других плакатов.

Скажем, у меня есть два проекта, назовите их CoreProject и AppProject. CoreProject является общим. В AppProject есть папка SharedBinaries. Именно на это указывают все ссылки на сборки.

Мой сценарий TFSBuild для CoreProject настроен на выполнение следующих действий:

-Получить последние

-Строить зону перетаскивания (что-то вроде \\ SERVER \ DropZone \ CoreProjectBuildNameAndNumber)

-Drop копируется в папку в зоне размещения (что-то вроде \\ SERVER \ DropZone \ Latest \ CoreProject)

Сценарий TFSBuild для AppProject настроен на выполнение следующих действий:

-Получить последние

- проверка файлов в папке SharedBinaries

-Копировать файлы из \\ SERVER \ DropZone \ Latest \ CoreProject

-Build

-Пропустить в зону удаления (что-то вроде \\ SERVER \ DropZone \ AppProjectBuildNameAndNumber)

-Если сборка прошла успешно, сборка копируется в зону размещения папок (что-то вроде \\ SERVER \ DropZone \ Latest \ AppProject), а файлы в SharedBinaries проверяются в

-Если сборка не удалась, файлы, скопированные в SharedBinaries, отменяют проверку.

Я обнаружил, что это работает очень хорошо. AppProject всегда строится с использованием самых последних битов из CoreProject, поэтому мы сразу знаем, есть ли существенные изменения. После проверки SharedBinaries в TFS я могу получить определенную версию и запустить код с теми же библиотеками из CoreProject, которые использовались в то время. Кроме того, мне просто нужно получить последнюю версию, и моя локальная машина также собирает последние версии.

Answer 3

Мы используем Репликатор зависимостей TFS , который может копировать файлы в любой проект в TFS после сборки проекта. У него нет отличной документации, но он, кажется, делает то, что должен, после того, как вы его настроите.

Сообщение в блоге Реализация репликации зависимостей с помощью TFS Team Build рекомендует настроить сценарий ветвления, чтобы помочь отслеживать, какие проекты используют какие зависимости, что также имеет смысл для меня.

Answer 4

Моя компания делает это, создавая папку «References», в которой хранятся все файлы .dll, необходимые для сборки сборок с внешними ссылками, поскольку папка bin фактически не сохраняется под контролем исходного кода.