Как сделать локальный запуск TFS Build удобным

Если ваш проект состоит не только из управляемого кода, и Вы используете Team Build, то, скорее всего, Вы уже заметили, что сборка solution на build машине не всегда проходит также гладко, как в IDE. К сожалению, порядок сборки проектов может отличаться, да и изменения исходных файлов не всегда отсеживаются корректно.

Хоть это и происходит редко, последствия крайне неприятны, особенно в том случае, если Вы используете непрерывную сборку. Представьте – разработчик собирает в IDE проект, и со спокойной душой кладёт изменения в систему контроля версий. Далее происходит сборка продукта и она ломается. Разработчик в недоумении. Все поледующие изменения, внесённые другими членами команды тоже приводят к сломанной сборке и проблема растёт как снежный ком (ну, конечно, если у Вас нет TFS 2010 и gated chek-in).

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

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

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

Проблема заключается в том, что умолчательные пути для результата сборки и тестов будут располагаться по вот такому пути “..\..\Binaries” и “..\..\TestResults” соответсвенно. Это ещё половина беды, так как самое страшное в этом случае то, что результат сборки будет просто выше по иерархии. Это не красиво, но не смертельно. Хуже другое – запуск коммандной строки

MSBuild TFSBuild.proj

в папке Build, где у меня лежит файл проекта сборки, просто сломается. Дело в том, что MSBuild будет искать solution файл в папке “..\..\Sources”. В моём случае не обойтись без параметров:

MSBuild TFSBuild.proj –p:SolutionRoot=..\

Согласитесь, что вспоминать все эти параметры в тех редких случаях, когда надо отладить процесс локальной сборки, не очень удобный вариант. Элегантное решение – поправить файл проекта таким образом, чтобы действовали умолчания, удобные Вам. Вставлю следующий кусок в проектный файл:

<PropertyGroup>

  <!-- Set default paths for desktop build -->

  <BuildDefinition Condition=" '$(IsDesktopBuild)' != 'false' and '$(BuildDefinition)' == '' ">DesktopBuild</BuildDefinition>

  <SolutionRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(SolutionRoot)' == '' ">$(MSBuildProjectDirectory)\..\</SolutionRoot>

  <DesktopBuildOutputRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(DesktopBuildOutputRoot)' == '' ">$(MSBuildProjectDirectory)\..\TfsDesktopBuild</DesktopBuildOutputRoot>

  <BinariesRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(BinariesRoot)' == '' ">$(DesktopBuildOutputRoot)\Binaries</BinariesRoot>

  <TestResultsRoot Condition=" '$(IsDesktopBuild)' != 'false' and '$(TestResultsRoot)' == '' ">$(DesktopBuildOutputRoot)\TestResults</TestResultsRoot>

</PropertyGroup>

Обращаю внимание, что сделать это надо до строки импорта TFS build проекта:

<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>

В своей реализации я оставил возможность для эстетов таки переопредилить и мои умолчания 🙂

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