Организация командной работы в Visual Studio

Question

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

Рабочая \ Deploy
Рабочая \ Sources

Все проекты находится в директории «Sources» и поставить DLL вывода в директории «Deploy».

Итак, представьте, что один работает над проектом «CoreLibrary», а выход dll - это CoreLibrary.dll, а второй работает над проектом «SomeLibrary», который используется в качестве ссылки CoreLibrary.dll. Это упрощенная ситуация, в реальной жизни этот проект может зависеть от многочисленных dll, которые являются предметом ответственности других разработчиков. В этом сценарии может быть такая ситуация, когда CoreLibrary изменяется после компиляции SomeLibrary. И, например, забыл сообщить другим разработчикам обновить свои ссылки. И эти изменения делают проект SomeLibrary не компиляцией, но он будет знать только во время выполнения -) Итак, чтобы избежать этого, мы решили дополнительно объединить все проекты в одном составном решении, где один проект, который должен ссылаться на другие, - это не выходная dll , поэтому если общие сборки решений означают, что все совместимо. Но есть одна проблема - для этого нам нужно изменить зависимость исходного проекта от dll к проекту. И если мы откроем автономный проект, мы выведем знак excalmation напротив этой ссылки, хотя проект все еще может быть скомпилирован.

I.e as заключение - у нас есть ссылки между проектами (каждый проект - атомная функциональность) через dll. Атомичность приводит к тому, что, когда мы меняем один «атом», мы должны проверить, совместимы ли эти изменения с другими зависимыми атомами. Это более удобно делать с общим решением, где мы загружаем последние источники и пытаемся скомпилировать. Но нам нужно изменить зависимости между проектами из dlls в проекты. Это, кажется, не совсем «правильно», поскольку ссылки на изменения в исходном автономном проекте. Создание одного большого решения для всех разработчиков, заставляющее их перекомпилировать все источники, и не только его проект также плох.

Answer 1

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