TFSBuild/MSBuild и ссылка на проект и ссылка на файл

Question

У нас есть большое решение для VS, использующее ссылки на проекты, которые создаются TFS Build следующим образом:

Solution
- Project 1
- Project 2
- Project ...
- Project N

Поскольку решение слишком большое, у нас есть несколько небольших решений, которые мы используем изо дня в день:

SubSolution
- Project 1
- Project 19

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

Это затем приводит к нарушению сборки TFS, которая не может найти эти ссылки на файлы, потому что они еще не были собраны (даже если проекты находятся в одном решении). Есть ли способ обойти это перетягивание каната между двумя типами ссылок. Как правильно разделить ваши решения?

Answer 1

Как правильно разделить ваши решения?

Прочтите эту главу из руководства TFS команды Patterns & Practices:

Глава 3 - Структурирование проектов и решений в управлении источниками

Обратите особое внимание на это примечание к сценарию "Partitioned Solution" (который, я полагаю, вы на самом деле пытаетесь реализовать):

В отличие от предыдущих версий Visual Studio, Visual Studio 2005 использует MSBuild. Теперь можно создавать структуры решений, которые не включают в себя все проекты, на которые есть ссылки, и которые все еще создаются без ошибок. Пока мастер-решение было построено первым, генерируя двоичный вывод из каждого проекта, MSBuild может следовать ссылкам на проекты за пределами вашего решения и успешно строить. Это работает, только если вы используете ссылки на проекты, а не ссылки на файлы. Вы можете успешно создавать решения, созданные таким образом, из командной строки сборки Visual Studio и из IDE, но не с Team Build по умолчанию. Для успешного построения с Team Build используйте мастер-решение, которое включает в себя все проекты и зависимости.

Answer 2

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

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

Мой совет - группировать ваши проекты в небольшие работоспособные решения и использовать ссылки на проекты в этих решениях. Ваш основной файл / сборка решения также может использовать ссылки на проекты, однако, если вы находите ссылки на проекты между меньшими решениями слишком сложными для обслуживания, вы можете вместо этого использовать ссылки на файлы и управлять порядком сборки через зависимости проекта или порядок сборки проекта (доступный в Visual Studio, щелкнув правой кнопкой мыши на проекте в вашем решении).