Вопрос

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

<Import Project="$(SolutionRoot)/libs/my.team.build/my.team.build.targets"/>

Мы не можем импортировать ни один файл в $(SolutionRoot) поскольку на момент проверки инструкции Import исходный код не был извлечен из репозитория.Похоже, что TFS сбрасывает TFSBuild.proj сначала без каких-либо других файлов.

Даже если мы добавим условный импорт, версия в системе управления версиями не будет импортирована, если она присутствует.Предыдущая версия, уже присутствующая на диске, будет импортирована.

Мы можем отказаться от хранения этих целей сборки в нашем исходном коде, но это первая зависимость, которая перемещается из нашего дерева исходных текстов, поэтому мы неохотно это делаем.

Есть ли способ сделать либо то, либо другое:

  1. Попросите Team Build удалить еще несколько файлов, чтобы эти Import заявления оцениваются правильно?
  2. Переопределите такие цели создания команды, как AfterCompile таким образом , помимо Import?
  3. В конечном счете запустить цели сборки в Team Build, которые хранятся в исходном коде, который он пытается создать?
Это было полезно?

Решение

Командная сборка проходит этап "начальной загрузки", когда все, что находится в папке конфигурации командной сборки (папка с TFSBuild.proj), загружается из системы управления версиями.Это выполняется агентом сборки перед вызовом агента сборки MSBuild.exe указание ему запустить TFSBuild.proj.

Если вы переместите свой целевой файл из-под SolutionRoot и поместите его в папку конфигурации рядом с файлом TFSBuild.proj, вы сможете импортировать его в свой файл TFSBuild.proj, используя относительную инструкцию импорта, т.е.

<Import Project="myTeamBuild.targets"/>

Если эти целевые объекты зависят от каких-либо дополнительных пользовательских сборок задач MSBuild, вы также можете хранить их в той же папке, что и ваш файл TFSBuild.proj, и вы можете легко ссылаться на них, используя относительный путь.

Обратите внимание, что в TFS2008 папка конфигурации сборки по умолчанию находится в папке $ /TeamProject/TeamBuildTypes, однако это не обязательно должно быть там.На самом деле он может находиться в папке, которая находится внутри вашего решения, и даже может быть проектом в вашем решении, предназначенным для командной сборки.Это имеет ряд преимуществ, включая упрощение ветвления сборки.Поэтому обычно моя сборка располагается в папке, подобной этой:

$/TeamProject/main/MySolution/TeamBuild

Также обратите внимание, что по умолчанию на этапе начальной загрузки сборки агент сборки загружает только файлы, которые находятся в папке конфигурации сборки, и не выполняет повторное копирование ни в какие вложенные папки.Если вы хотели, чтобы он включал файлы во вложенные папки на этапе начальной загрузки, вы можете установить следующее свойство в настройках приложений файла tfsbuildserver.exe.config на компьютерах агента сборки (расположен в %ProgramFiles%\ Visual Studio 9.0\Common7 \ IDE \PrivateAssemblies)

<add key="ConfigurationFolderRecursionType" value="Full" />

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

Удачи вам,

Мартин.

Другие советы

Если целевые объекты должны запускаться только тогда, когда TFS выполняет сборку, а не на ваших локальных компьютерах разработки, вы можете поместить свой целевой файл в папку для самой сборки и ссылаться на него с помощью:

<Import Project="$(MSBuildProjectDirectory)\my.team.build.targets.proj" />

Однако, если вы хотите, чтобы целевые объекты выполнялись для всех сборок, вы можете настроить их так, чтобы отдельные проекты ссылались на них, добавив что-то вроде:

<Import Project="$(SolutionRoot)/libs/my.team.build/my.team.build.targets" Condition="Exists('$(SolutionRoot)/libs/my.team.build/my.team.build.targets')" />

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

Если вы создадите целевой файл переопределения для импорта и назовете его чем-то вроде TeamBuildOverrides.targets и поместите его в ту же папку в системе управления версиями, где находится TFSBuild.proj для вашего типа сборки, он будет извлечен первым и будет доступен для импорта в файл TFSBuild.proj.По умолчанию файл TFSBuild.proj добавляется в папку TeamBuildTypes в системе управления версиями непосредственно под корневой папкой вашего проекта.

используйте следующую инструкцию import в вашем файле TFSBuild.proj:

<Import Project="$(MSBuildProjectDirectory)\TeamBuildOverrides.targets" />

Убедитесь, что у вас нет повторяющихся переопределений в вашем файле TFSBuild.proj, иначе импортированные переопределения не будут запущены.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top