Управление зависимостями с TFS 2010

Question

Каков наилучший способ управления зависимостями с TFS 2010?

EDIT: Я хотел бы знать, существует ли такая система, как Maven или NuGet, которая позволяет легко управлять зависимостями .dll (внешними или созданными нашей командой) внутри TFS 2010. Однако мы сталкиваемся с проблемой, заключающейся в том, что мы хотим иметь возможность изменять код нашей dll и тестировать в режиме реального времени, если они работают (без публикации нового пакета).

Answer 1

На самом деле довольно просто вызвать NuGet в качестве шага перед сборкой.Вы можете переопределить цель BeforeBuild в вашем *. * Proj-файле для проекта со ссылками NuGet.

<Target Name="BeforeBuild">
  <Exec Command="&quot;$(SolutionDir)Tools\nuget&quot; install &quot;$(ProjectDir)packages.config&quot; -o &quot;$(SolutionDir)Packages&quot;" Condition="'$(BuildingInsideVisualStudio)'==''" />
</Target>

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

Далее вам нужно проверить файл packages.config изкаталог вашего проекта, но не папка пакетов под каталогом вашего решения.Обратите внимание, что я включил проверку $ (BuildingInsideVisualStudio) для , а не , чтобы быть установленным на этапе предварительной сборки выше.Это приведет к загрузке и установке пакетов во время сборки при сборке с помощью службы сборки TFS (или из командной строки).Это не повлияет на ваш опыт работы с NuGet в Visual Studio.

Вы можете искать статьи по автоматизации создания пакетов NuGet с помощью TFS - довольно много людей написали об этом в блоге.Сочетание этих двух факторов делает возможным очень эффективное решение для управления зависимостями.Теперь нам просто нужен канал NuGet, встроенный в TFS;).

Answer 2

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

Вот три ссылки на статьи, которые касаются этой темы:

http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx

http://blog.ehn.nu/2009/03/implementing-dependency-replication-with-tfs-team-build/

http://blog.ehn.nu/2010/12/dependency-replication-with-tfs-2010-build/

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

Answer 3

Когда вы создаете сборку Continuous Integration в TFS 2010, сборка запускается всякий раз, когда что-то регистрируется в одной из папок управления исходным кодом, соответствующих рабочей области, определенной для сборки. Вы можете попытаться создать папку управления исходным кодом для используемых вами библиотек DLL, а затем включить эту папку в рабочее пространство каждого проекта, в котором они нужны.

Когда вы определяете сборки CI и регистрируете новую версию одной из этих DLL, это вызовет сборку CI всех проектов, которые используют DLL. Конечно, сборка CI будет не только создавать код, но и запускать модульные тесты.