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

Ответ 1

Я работал над продуктами по обоим крайностям: один с ~ 100 проектами в одном решении и один s > 20 решениями по 4-5 проектов каждый (Test, Business Layer, API и т.д.).

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

Я работал над решением, имеющим около 200 проектов. Это не имеет большого значения, если у вас достаточно ОЗУ:).

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

В других ответах сказано, однако, вероятно, стоит сказать еще раз.

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

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

С зависимостями проекта он будет сортировать все для вас.

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

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

Ответ 11

При выборе количества проектов и решений вам нужно уделить несколько вопросов:

• логические уровни вашего приложения;
• зависимость между проектами;
• как создаются проекты;
• кто работает с какими проектами;

В настоящее время у нас есть 1 решение с 70 проектами. Для нашей непрерывной интеграции мы создали 5 проектов msbuild, поэтому CI не создает наше решение для разработки.

Раньше у нас было отдельное решение для представления (веб-и связанных проектов) в отдельном репозитории git. Это решение было использовано сторонними и внештатными веб-разработчиками.

Ответ 12

Я работаю с решением, которое в настоящее время имеет 405 проектов. На очень быстрой машине это выполнимо, но только с текущей версией Visual Studio 2017 или 2012. Другие версии часто выходят из строя.