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

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

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

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

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

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

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

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

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

На самом деле есть два хороших способа заставить это загореться.

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

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