Как вы разделяете решение Visual Studio?

Ответ 1

Там нет хорошего способа сделать это. Инструменты не построены с учетом этого. Вместо этого вы должны объединить свои проекты вместе, насколько сможете. Даже при том же объеме кода, сборки будут работать во много раз быстрее.

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

Ответ 2

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

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

Решение → Щелкните правой кнопкой мыши → Диспетчер конфигурации → снимите флажок Создать в любых проектах, которые не меняются и не нужны каждая конструкция по другой причине. Это ускоряет вашу сборку, используя вывод последней сборки этих проектов, откуда бы они не сбрасывали свои двоичные файлы.

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

Обновление
В духе перехода на маршрут производительности (например, до тех пор, пока не будет VS 2010), вы приняли меры, перечисленные в некоторых других вопросах: Очень медленное время компиляции в Visual Studio и Оптимизация Visual Studio? Это может иметь большое значение и может привести к повышению производительности до приемлемого уровня, в то время как ждет, когда VS 2010 отправит.
Еще несколько вещей, которые могут оказать хорошее влияние на производительность:

• я настоятельно рекомендую SSD, если это опция. Они дорогостоящие, но, безусловно, стоит того, чем больше файлов в вашем решении, тем больше они окупаются. Когда мы заказали новые машины на работе, вся команда разработчиков отправилась с SSD, разница поразительна. Когда вы имеете дело с большим решением, оно вращает диск вокруг переключения физической головы на тысячи мест, чтобы читать файлы в..., где SSD-диски выигрывают, время поиска составляет 0мс.
• В то же время бесплатное решение является хорошим драфрагментатором (только если вы на физическом уровне, НЕ дефрагментируете SSD), имеет большое значение... если вы используете что-то, что учитывая визуальную студию. Я рекомендую MyDefrag (freeware), так как его собственный алгоритм для дефрагментации сохраняет структуру каталогов, поэтому, по крайней мере, физический диск не тратит так много времени, чтобы разогнать файлы, которые вам нужны в вашем решении, все они очень близки на диске.
• С учетом вышеприведенного предложения SSD, имейте в виду, что существует огромное несоответствие производительности SSD между дешевым и быстрым приводом, сделайте здесь немного исследований. Не беспокойтесь о своей системе, используя бесплатную утилиту например gParted, вы можете легко перемещать весь ваш диск ОС, а ваш старый диск все равно будет резервной копией... пока SSD может соответствовать данным с вашего C, вы хорошо.

Ответ 3

Вы можете сделать несколько решений и добавить любой проект в каждое решение, которое вам нравится.

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

Так что подумайте о них как о "библиотеках" (скомпилированных один раз, а затем много) и "основных" проектах (которые вы сильно меняете). Сделайте решение для размещения ваших "библиотечных" проектов и (желательно) добавьте шаг после сборки, который копирует полученные DLL отладки/выпуска в папки общих библиотек. Добавьте основные проекты в новое решение. Измените все ссылки на основные решения, чтобы ссылаться на ваши библиотеки с помощью встроенных бинарных библиотек DLL в общих папках (обратитесь к документации dll release, чтобы ваша окончательная версия работала правильно).

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

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

Ответ 4

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

Мы закончили построение собственного инструмента в виде soldr (с открытым исходным кодом), промежуточное решение построить инструмент. Он может опционально использовать nuget, чтобы управлять своей базой кода или работать самостоятельно. Идея состоит в том, чтобы разделить вашу работу на столько решений (.sln), что логически логично. В нашем случае у нас есть один для нашей внутренней структуры, а затем один sln для каждой нашей библиотеки back end, по одному для каждого продукта и т.д. Каждое решение имеет каталог "компонентов" (аналогичный пакет "duget" ) где хранятся фактические файлы библиотек (DLL и т.д.), на которые ссылается текущее решение. Эти DLL файлы должны быть обновлены из новой сборки зависимости для целевого sln, чтобы увидеть новую версию.

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

Обновить. Чтобы использовать nuget, мы добавили поддержку для генерации файлов nuspec с автоматически определяемыми зависимостями.

Ответ 5

Другой вариант - иметь одно всеобъемлющее решение и создавать различные конфигурации компоновки.

В верхней части окна находится поле со списком, в котором вы можете выбрать конфигурацию конфигурации Debug или Release. Отбросьте это и выберите опцию "Configuration Manager...".

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

Теперь ваша конфигурация сборки "CoreOnly" появится в окне. Он отображает список всех проектов. Для любых проектов, которые вы не хотите создавать, установите флажок "Построить" в правой колонке. Закройте диалоговое окно.

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

сторонние стороны этого подхода заключаются в том, что решение может быть очень медленным для открытия (хотя в Visual Studio 2008, Visual Studio 2010 и Visual Studio &nbsp, 2012, это намного лучше, чем в Visual Studio 2005, поэтому у вас может не возникнуть проблема с ним ) и что если проект не включен в вашей конфигурации, он никогда не будет восстановлен, и поэтому ваша сборка (или работающее приложение) может развалиться - вам нужно помнить о том, чтобы вернуться к обычной конфигурации "построить все" если вы считаете, что внесли изменения (или повлияли) на проекты с ограниченными возможностями.

Ответ 6

У вас должно быть разделение проблем, особенно при группировке проектов в решении Visual Studio. Я недавно столкнулся с этой проблемой на работе, где мне пришлось создать кучу модульных тестов, и исходный тест, созданный разработчиком, был включен в решение. Сначала я подумал, что О.К. Я просто поставил свои тесты здесь. B/c. Я знаю, что это сработает и вам не придется беспокоиться о том, чтобы получить зависимости. Но потом, после того, как я добавил, что 20 тестовых проектов для каждой отдельной единицы, я понял, что она строилась так невероятно медленно.

Затем я решил создать решение для КАЖДОГО набора тестов, а не помещать их в одно место. Это также помогает лучше упорядочить код, чтобы его легче было найти. Например, я создал папку "Test > Unit > MyUnitTest" и "Test > Integration > MyIntegrationTest". Это не только облегчает поиск вещей позже, но и помогает вам быстрее создавать свои сборки. Кроме того, если куча людей, работающих с кодом сразу, каждый разработчик может потенциально изменить настройки и конфигурации проекта, а не испортить другие.

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

Ответ 7

У нас есть 500 проектов в решении. Есть преимущества для каждого проекта в одном решении, особенно при изменении базового проекта, который влияет на все другие проекты (например, вспомогательные классы).

Мы нашли лучший способ продолжить использовать расширение vsFunnel для Visual Studio. Он имеет возможность загружать решение БЕЗ проектов. Проекты все еще перечислены в решении, но фактически не загружены до тех пор, пока это не будет необходимо. Когда проект открывается через пользовательский интерфейс, он загружается по требованию.

Реальный трюк - включить "Load Dependencies" из пользовательского интерфейса vsFunnel. Когда вы открываете проект, он загружает все зависимые проекты и т.д., Что значительно облегчает работу над целевым проектом.

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

Подсказка: выберите Load Dependencies AND Load None - тогда, когда вы открываете свой целевой проект в пользовательском интерфейсе, загружаются все связанные проекты.

Это оказалось огромной экономией времени (плюс SSD-накопитель!)

Ответ 8

Кроме того, здесь упоминается soldr и Воронка Я могу рекомендовать использовать Диспетчер загрузки приложений. Да, SSD помогает, но VS - глючит: он падает, становится невосприимчивым и возникают другие проблемы при работе над более чем 100 проектами. Сохраняя все это вместе для основного рефакторинга, требуется перестройка и отладка, но работа над меньшими подмножествами проектов на ежедневной основе значительно улучшит производительность и удовлетворенность.

пс. Я хотел бы узнать, сделал ли кто-нибудь сравнение воронки или диспетчера загрузки приложения?