Количество проектов в решении Visual Studio 9 влияют на загрузку решения и время изготовления?

50-60 походит на много мне. Я нахожу, что с большим количеством проектов, открытие Visual Studio может занять много времени. Время изготовления может быть плохим при изменении проекта, от которого зависит много других проектов, но я не знаю, как отличающийся, который является между 10 проектами с 20 классами в каждом и 100 проектами с 2 проектами в каждом. (Другими словами, я не уверен в издержках на проект в здании.), Даже когда Вы ничего не изменяете, по-видимому, каждый проект должен обнаружить, должен ли он восстановить что-нибудь - я не могу предположить, что это свободно, но трудно дать что-либо более определенное, не пробуя его Вашим собственным кодом.

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

Если Вы на самом деле получили разумно измеренные проекты, просто многие из них, рассмотрите разделение решения, если это возможно. Если они - все крошечные проекты, рассматривают объединение некоторых из них. Если Вы не ожидаете Visual Studio, так или иначе (открывающейся/создающей), затем не волнуются слишком много.

(Мне конкретно интересно во время загрузки решения и время изготовления - меньше решений означает лучшую производительность?)

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

Я поощряю Вас читать блог Patrick. У него есть много статей о компонентизации кода.

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

Уроки извлечены из кодовой базы NUnit

Подсказки, о том, как разбитому на компоненты существующему коду.

От моего личного опыта это - боль, чтобы иметь решение с несколькими десятками проектов. IMO наличие больше чем 10 проектов будет приводить к значимым проблемам обслуживания и влиять на Вашу производительность.

Это - плохая идея иметь слишком много проектов в Вашем решении. Это влияет на время изготовления. См. эту статью, которая делает сравнение времени изготовления с несколькими инструментами сборки. В соответствии со статьей, Visual Studio занимает 2 секунды на проект, даже если проект не является частью сборки.

Это также соответствует моему опыту, что Visual Studio является одним из самого медленного доступного инструмента сборки. Между Visual Studio 6 и 2006, мое время изготовления переместило с без одной минуты 5 минуты для относительно простого проекта C.

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

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

Общее количество 2/блоков: Как Aku записал, меньше проектов означает меньше блоков. Начиная с каждой копии проекта локально блоки, которые они используют, Вы могли добраться (n * (n - 1)) / 2 блока в Ваших папках (49 копий блока 1, 48 из блока 2...). Для 50 проектов это - 1 176 файлов! => хорошо, Вы, вероятно, имеете намного меньше (200?), но этого все еще достаточно для получения копии или двух устаревших тут и там...

Я работаю над проектом с большим количеством проектов в области 50-60, и я нашел, что долгое время загрузки приемлемо по сравнению с проблемами, связанными с ленивостью разработчика / забвение.

Много проектов зависит от основных библиотек и таким образом должно быть восстановлено, когда основная библиотека изменяется. Поскольку проекты могут быть в некотором потоке в любой момент времени, имение разработчиков только работает над средствами подмножества, что, если они ленивы, они не восстановят целое приложение, когда обновление будет получено от инструмента CM. Они могут затем провести огромное количество времени, пытающееся починить вещи, понимающие, почему вещи повреждаются. Это все решено, если все дерево зависимостей известно VS и быстрой сборкой - все могут заставить все это работать правильно.

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

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

И несколько слов Microsoft ...

http://tfsguide.codeplex.com/Wiki/View.aspx?title=Chapter%203%20-%20Structuring%20Projects%20and % 20Solutions% 20in% 20Source% 20Control

Обычно я стараюсь придерживаться 4-5 проектов на одно решение.

• Business Logic
• Коммуникационный уровень (связанный с сервером)
• Пользовательский интерфейс
• Тестирование Проект для использования / тестирования трех других проектов

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

Поздно к вечеринке, но пока ни в одном из ответов не упоминаются конфигурации сборки. В вашем решении МОЖЕТ быть множество проектов, при этом все они не будут создаваться каждый раз при запуске. Щелкните комбинацию «Отладка / Выпуск» и создайте новую конфигурацию сборки - там вы можете решить, какие проекты вы хотите создавать или нет.

Зачем это нужно? Я делаю это для того, чтобы я мог «перейти к определению» по своему желанию, и чтобы я мог быстро менять проекты в моей сборке и из нее, не проходя через всю боль Добавить проект.

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