TFSBuild/MSBuild и Project Ссылка против Reference File

Question

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

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

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

SubSolution 
- Project 1 
- Project 19 

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

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

Answer 1

Каков правильный способ разделения ваших решений?

Проверить эту главу из руководства TFS по Patterns & Практики Команда:

Chapter 3 - Structuring Projects and Solutions in Source Control

Обратите особое внимание на эту записку к сценарию «Разделенный Solution» (который я тебе верю» на самом деле пытаются реализовать):

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

Answer 2

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

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

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