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

Question

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

Обратите внимание, что я не , говоря о производительности встроенного приложения.

Является ли время загрузки и время сборки более эффективным при работе с меньшим числом проектов?

В качестве руководства у нас есть 50-60 проектов в нашем решении Visual Studio.

Answer 1

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

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

Я советую вам прочитать блог Патрика. У него много статей о компонентизации кода.

Советы по разбиению кода через сборки .NET

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

Советы по компоновке существующего кода.

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

Answer 2

Я зависит от вашего проекта, большую часть времени я работаю с 10-15. Чем меньше проектов, тем меньше время сборки.

Проекты, которые у меня обычно есть:

• базовый проект с исключениями и обработкой ошибок
• бизнес-логика
• уровень доступа к данным - хранилище
• WebForms ИЛИ WinForms ИЛИ WPF UI

Некоторые из них я бы разделил на 3-4 других проекта. У меня также были бы тестовые проекты NUnit.

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

Answer 10

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