TFSBuild/MSBuild и Ссылка проекта по сравнению со Ссылкой на файл
У нас Есть большое решение VS с помощью ссылок проекта, который является сборкой Сборкой TFS как так:
Solution
- Project 1
- Project 2
- Project ...
- Project N
Поскольку решение является слишком большим, у нас есть несколько меньших решений, которые мы повседневно используем:
SubSolution
- Project 1
- Project 19
Проблема состоит в том, что разработчики, работающие над SubSolution, находят, что он не создает, потому что ссылки проекта не могли быть найдены, таким образом, они изменяют проекты использовать ссылки на файл.
Это затем продолжает повреждать Сборку TFS, которая не может найти эти ссылки на файл, потому что они еще не были созданы (Даже при том, что проекты находятся в том же решении). Есть ли путь вокруг этого перетягивания каната между двумя типами ссылок. Каков корректный способ разделить Ваши решения?
2 ответа
Каков правильный способ разделения ваших решений?
Ознакомьтесь с этой главой из руководства TFS, составленного командой Patterns & Practices:
Глава 3 - Структурирование проектов и решений в Source Control
Обратите особое внимание на это примечание к сценарию «Partitioned Solution» (который, я полагаю, вы действительно пытаетесь реализовать):
В отличие от предыдущих версий Visual Studio, Visual Studio 2005 полагается на MSBuild. Теперь можно создавать структуры решений, которые не включают все проекты, на которые есть ссылки, и по-прежнему строятся без ошибок. Пока главное решение было построено первым, генерируя двоичный вывод из каждого проекта, MSBuild может следовать ссылкам на проекты за пределами вашего решения и успешно строить. Это работает, только если вы используете ссылки на проекты, а не на файлы. Вы можете успешно создавать решения, созданные таким образом, из командной строки сборки Visual Studio и из IDE, но не с помощью Team Build по умолчанию. Для успешной сборки с помощью Team Build используйте основное решение, которое включает в себя все проекты и зависимости.
Независимо от того, как вы организуете свою сборку, разработчики должны понимать, как работают ссылки , и знать, когда они вносят изменения в ссылки, что они не должны проверять эти изменения в , если они не собирались внести изменения в процесс сборки .
Что касается организации ваших сборок - как говорит Дмитрий, ссылки на проекты должны работать между решениями (пока цель уже построена, однако в любом случае это также относится к ссылкам на файлы).
Я бы посоветовал сгруппировать ваши проекты в небольшие работоспособные решения и использовать в них ссылки на проекты. Ваш основной файл / сборка решения также может использовать ссылки на проекты, однако, если вы обнаружите, что ссылки на проекты между меньшими решениями слишком сложны для обслуживания, вы можете вместо этого использовать ссылки на файлы и управлять порядком сборки через зависимости проекта или порядок сборки проекта (доступный в Visual Studio, щелкнув правой кнопкой мыши проект в своем решении).