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

Question

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

Рабочая \ Deploy
Рабочая \ Источники

Все проекты находятся в каталоге "Sources" и помещают dll вывода в каталог "Deploy".

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

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

Answer 1

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