TFS 2010 Build Automation и событие после сборки

В проекте, который я унаследовал, оригинальный разработчик использовал несколько событий после сборки в своих проектах Visual Studio для копирования вокруг DLL и т.д. при построении внутри VS.

Это вызывает некоторую скорбь сейчас, когда я пытаюсь переместить эти вещи в систему TFS 2010 Build.

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

Любые идеи? Есть ли что-то, что я мог проверить, чтобы знать, что я работаю под TFS Build, а затем просто пропустить эти файлы CMD? Любые идеи были бы наиболее желанными!

Ответы

Ответ 1

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

Вы могли бы объединить все свои шаги сборки post в один script, возможно, а затем просто проверить переменную окружения в начале этого script.

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

Итак, в вашей сборке TFS script у вас будет что-то вроде:

<RunScripts Condition=" '$(RunScriptsServerVar)' != '' ">
            the environment var is NOT set, so run your scripts since we aren't in
            a TFS build
</RunScripts>

Ответ 2

Мой подход состоит в том, чтобы защитить код pre- или post-build с помощью этого

IF "$(BuildingInsideVisualStudio)"=="true" ( ... ваш код здесь... )

Эта переменная автоматически определяется Visual Studio, и вам не нужно изменять определение сборки.

Ответ 3

Я использую подобный подход для этого. Я добавляю следующие шаги для каждого этапа после сборки:

if '$(TeamBuild)'=='True' exit 0

Затем при настройке определения сборки я просто добавляю:

/p:TeamBuild=True

... в аргументы MSBuild.

Это дает мне гибкость для сохранения всех конфигураций в проектах и ​​определении сборки.