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

Question

Мы начинаем разработку нового приложения, которое будет включать в себя примерно 30-50 проектов, разработанных примерно десятком разработчиков с C# в MS Visual Studio.

Я работаю над компоновкой модулей приложения для поддержки архитектуры и обеспечения параллельной работы.

Мы утверждаем: сколько у нас решений?

Некоторые утверждают, что у нас должно быть 1-2 решения с 15-30 проектами каждый. Некоторые утверждают, что нам нужно решение для каждого компонента, что означает около 10-12 решений по 3-6 проектов каждый.

Я был бы рад услышать плюсы/минусы и опыт с каждого направления (или другое направление его)

Благодаря

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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

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

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

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

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

Answer 10

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

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

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

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

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

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

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

Answer 11

Решая, какое количество проектов против решения вам нужно, вы должны рассмотривать некоторые вопросы:

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

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

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