TFSBuild/MSBuild и справочник по проекту и справочник по файлам

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

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

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

SubSolution
- Project 1
- Project 19

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

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


tfs msbuild project-reference tfsbuild projects-and-solutions
person anon    schedule 05.03.2010    source источник
comment
Возможно, вы могли бы попытаться добавить зависимость (DependsOn) для подпроектов от основных строящихся?   -  person mfloryan    schedule 09.03.2010

Ответы (2)


arrow_upward
2
arrow_downward

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

Ознакомьтесь с этой главой из руководства по TFS от команды Patterns & Practices:

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

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

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

person DmytroL    schedule 18.06.2010

arrow_upward
2
arrow_downward

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

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

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

person Justin    schedule 18.06.2010