Сборка TFS 2013 - путь вывода сборки библиотеки классов ничего не значит?

Я надеюсь, что кто-то может помочь мне с этим. У меня есть решение, состоящее из двух веб-сайтов и двух библиотек классов. Одна из библиотек классов является общей библиотекой для использования во многих наших проектах, поэтому ее выходные данные хранятся в общем месте (D:\Applications\SharedLibraries\Bus_logic), чтобы мы могли ссылаться на dll оттуда. У нас есть эта структура каталогов на наших локальных машинах и на сервере сборки.

Это отлично работает на моей локальной машине. Локальное построение решения отправляет обновленную библиотеку DLL в локальную папку D:\Applications\SharedLibraries\Bus_logic. Наши старые сборки CCNet будут делать то же самое на сервере сборки.

Однако с TFS выходной путь библиотеки классов не имеет значения. У меня есть сборка CI для решения, и библиотеки классов никогда не выводятся по этому пути. Они просто сгруппированы в папке drop.

Есть ли какой-нибудь простой способ убедиться, что сборка копирует эти DLL в их законные местоположения, или мне нужно создать собственный шаблон сборки для каждого из моих решений, который компилирует общие библиотеки, чтобы DLL копировались в правильный каталог?


tfs build c# tfsbuild
person Barry Gallagher    schedule 01.07.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Недавно я занимался сборкой TFS, поэтому надеюсь, что следующее поможет.

Прежде чем делать что-либо из следующего, я рекомендую вам создать новое определение сборки и новый шаблон сборки (через «Редактировать определение сборки» -> «Процесс» -> «Новый шаблон» -> «Копировать из существующего»), чтобы проверить, как это работает.

TFS предоставляет пользовательский путь для аргумента OutDir для MSBuild, переменная, передаваемая для этого, называется outputDirectory. Шаг, на котором это установлено, находится глубоко внутри шаблона сборки по умолчанию, откройте его и перейдите к «Запуск на агенте» -> «Попробовать скомпилировать, протестировать и связать» -> «Последовательность» -> «Компилировать, протестировать и связать» -> «Попробовать скомпилировать и протестировать». > Компилировать и тестировать -> Для каждой конфигурации -> Компилировать и тестировать -> Инициализировать переменные. Там вы найдете задачу Initialize OutputDirectory, которая по умолчанию установлена ​​в папку BinariesDirectory/Platform/Configuration. Вы можете изменить это на свою собственную логику.

Возможно, проще было бы ничего не указывать для аргумента OurDir в задаче «Выполнить MSBuild», поскольку я предполагаю, что тогда будут использоваться пути проектов по умолчанию. Это можно найти здесь, в шаблоне, «Запуск на агенте» -> «Попробовать скомпилировать, протестировать и связать» -> «Последовательность» -> «Компилировать, протестировать и связать» -> «Попробовать скомпилировать и протестировать» -> «Скомпилировать и протестировать» -> «Для каждой конфигурации» -> «Скомпилировать и Тест -> Если BuildSettings.HasProjectsToBuild -> Для каждого проекта -> Попытаться скомпилировать проект -> Скомпилировать проект.

Вероятно, есть более элегантный способ — возиться с файлами решения или проекта, но я пока об этом не знаю.

person Cardinal    schedule 01.07.2014

arrow_upward
0
arrow_downward

Есть действительно два хороших способа заставить это светиться.

  1. Проверьте dll - вы можете создать папку в исходном коде с файлами, от которых вы зависите, зарегистрированными. Затем добавьте сопоставление в сборке, чтобы получить их в известном месте.
  2. Вы можете упаковать DLL как пакет NuGet и зависеть от него.

1 дешево и сердито и часто ошибается, но не так сильно, как ваше текущее решение. # 2 - правильный способ делать что-то. NuGet был разработан для решения подобных проблем.

person MrHinsh - Martin Hinshelwood    schedule 04.07.2014