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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

В блоге Implementing Dependency Replication with TFS Team Build рекомендуется настроить сценарий ветвления, чтобы помочь отслеживать, какие проекты используют зависимости, что имеет смысл и для меня.

Answer 4

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

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

Мой TFSBuild сценарий CoreProject настроен сделать следующее:

-get Последние

-Build падение падение зоны (что-то вроде \\ SERVER \ DropZone \ CoreProjectBuildNameAndNumber)

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

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

-get Последние

-Проверят файлы в папке SharedBinaries

-CoPY файлов из \\ SERVER \ DropZone \ Последних \ CoreProject

-Build

-Drop уронить зоны (что-то вроде \\ SERVER \ DropZone \ AppProjectBuildNameAndNumber)

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

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

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