Рекомендуемое количество проектов в Решении для Visual Studio

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

Редактирование: Это означает, что Вы не должны прикреплять проекты, которые не зависят друг от друга в то же решение, как оно создает иллюзию зависимости, что означает, что кто-то мог создать реальную зависимость, когда два проекта должны действительно быть независимыми.

Я работал над решением с близко к 200 проектам. Это не имеет большого значения, если у Вас есть достаточно RAM :).

Одна важная вещь помнить, это - проекты, зависят друг от друга (быть этим с Зависимостями или Ссылками), они должны, вероятно, быть в том же решении. Иначе Вы получаете странное поведение, когда различные проекты имеют различные зависимости в различных решениях.

Вы хотите поддержать ссылки проекта. Если можно безопасно разбить решение с двумя или больше дискретными наборами проектов, которые зависят друг от друга, то сделайте это. Если Вы не можете, то они все принадлежат вместе.

У нас есть решение, которое имеет приблизительно 130 проектов. Приблизительно 3 года назад, когда мы используем vs.net 2003, это была ужасная проблема. Иногда решение и VSS отказывали.

, Но теперь с VS.NET 2005 это в порядке. Только загрузка занимает время. Некоторые мои коллеги, разгружающие проекты, которые они не используют. Это - другая опция убыстриться.

Изменяющийся тип сборки для выпуска является другой проблемой. Но у нас есть сценарии MSBuild теперь. Мы не используем сборку выпуска VS.NET больше.

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

Как правило я гравитировал бы к сокращению числа проектов (сделайте проект немного более универсальным), и имейте devs, совместно используют управление исходным кодом на тех проектах, но разделяют функциональность в рамках тех проектов подпространствами имен.

Я думаю, что Вы не должны преувеличивать свое количество проектов/решений. Разбейте на компоненты то, что может
и будет снова использовано, иначе не разбивайте на компоненты! Это только сделает вещи менее прозрачными и увеличит время изготовления. Разделение может также быть сделано в папке использования проекта или использовании логической структуры класса.

Я не думаю фактическое количество вопросов решений. Намного более важный то, что Вы разбиваете вещь вдоль функциональных строк. Как глупый, изобретенный пример, если у Вас есть муфта библиотек, которая обрабатывает interop с внешними веб-сервисами, которые были бы решением; EXE с DLLs, это должно работать, был бы другим.

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

Это было сказано в других ответах однако, это, вероятно, стоит повторить.

зависимости Проекта хороши в этом, они могут восстановить зависимые проекты, если зависимость имеет изменение.

, Если Вы, зависимость от файла блока там не является никаким способом, которым VS или MSBuild собираются знать, что строка проектов должна быть создана. То, что произойдет, - то, которые на первом разрабатывают проект, который изменился, будет восстановлен. При помещении зависимости от вывода сборки затем, по крайней мере, на второй сборке, проект, зависящий от этого, создаст. Но затем у Вас есть неизвестное количество сборок, должен был добраться в конец цепочки.

С зависимостями проекта это уладит все это для Вас.

Так ответ, который, как, который говорит, имеют как, многие (или немногие) по мере необходимости для обеспечения зависимостей проекта используются.

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

Я работал над продуктами в обоих направлениях: один с ~ 100 проектами в одном решении, а другой - с> 20 решениями, по 4-5 проектов каждое (тест, бизнес-уровень, API и т. д.).

Каждый подход имеет свои преимущества и недостатки.

Единое решение очень полезно при внесении изменений - его легче работать с зависимостями и позволяет инструментам рефакторинга работать хорошо. Однако это приводит к увеличению времени загрузки и времени сборки.

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

Может быть, есть » Для гибридного подхода используйте по большей части меньшие решения, но создайте единое, включающее все проекты, на случай, когда требуются более масштабные изменения. Конечно, тогда вам придется поддерживать два отдельных решения ...

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

И имейте в виду, в конечном итоге RAM дешевле, чем время программиста ...