Управление зависимостями системы контроля версий в Visual Studio Team System

Как использовать данную статью

• Раздел «Использование проектов» рассказывает о том, как работать со ссылками на другие проекты, как внутренними, так и внешними по отношению к текущему групповому проекту.
• Раздел «Использование сборок сторонних производителей» рассказывает, как работать со ссылками на сборки сторонних производителей, исходным кодом которых вы не располагаете.
• Раздел «Использование Веб-сервисов» рассказывает, как работать со ссылками на совместно используемые Веб-сервисы в среде коллективной разработки.
• Раздел «Использование баз данных» рассказывает, как соединяться с базами данных и использовать их в среде коллективной разработки.

Сценарии и решения

1. Используется сборка, сформированная другим проектом в том же решении.
2. Используется сборка, сформированная другим проектом в другом решении.
3. Используется сборка из другого группового проекта.
4. Используется сборка стороннего производителя.

Использование сборок, сформированных другим проектом в том же решении

Использование сборок, сформированных проектами других решений

• Использовать ссылку на двоичный файл сборки.
• Добавить проект Visual Studio (файлы проектов и исходные файлы) в решение и затем использовать ссылку на проект.

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

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

Использование сборки из другого группового проекта

При совместном использовании исходного кода или двоичных файлов в групповых проектах возможны два варианта:

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

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

При ветвлении возникают дополнительные издержки на слияние, они влияют на решение, использовать ли обновления в виде бинарных файлов или в виде исходного кода.

Использование сборки стороннего производителя

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