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

Question

У меня есть решение Visual Studio 2008 с> 40 C# и C++/CLI проектами, которые зависят друг от друга. Работа с этим решением довольно медленная, и обычно мне нужно всего несколько проектов за раз. Поэтому я решил разделить решение на несколько решений, содержащих 3-5 проектов. Я также хотел бы сохранить «полное» решение со всеми проектами (он удобен для автоматизированных сборок или для больших действий по рефакторингу, которые влияют на все проекты). (Это основное условие здесь. В противном случае разделение проектов на решения тривиально, конечно.)

Есть ли способ сделать это?

Моя первая идея заключалась в создании новых пустых решений и добавлении некоторых существующих файлов проектов в каждое из этих решений. Но если я это сделаю, VS больше не сможет найти ссылки на проект (потому что они не в одном решении). Я могу добавить ссылки как «нормальные» ссылки на файлы. Но если я это сделаю, мое «полное» решение больше не работает, потому что зависимости теряются.

EDIT:

Спасибо всем за ваши ответы. Я хотел бы немного уточнить свой вопрос: мое решение содержит 44 проекта, не считая тестов. Так что разбить его на 2 части - это не то, что я имел в виду, я больше думал о 5-8 частях. Вот почему я хотел бы сохранить «полное» решение, в котором VS может определить правильный порядок сборки для полной сборки. Поддержание порядка сборки для 8 отдельных решений вручную (например, в пакетном файле) кажется мне уязвимым.

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

A is referenced by B is referenced by C is referenced by D 

и представить себе, что А и D часто модифицирована вместе, но В и С изменяются редко. (Очевидно, что интерфейс A, который используется B, для этого не должен оставаться неизменным.) Тогда я хотел бы иметь A и D в одном решении, B и C в другом. Но это будет работать только в том случае, если я смогу иметь неповрежденное «полное» решение, содержащее A, B, C и D, если я хочу построить все проекты с нуля. Как только эта сборка будет завершена, я смогу открыть свое A/D-решение и отредактировать/построить только те 2 проекта.

Но я боюсь, что для моей проблемы нет элегантного решения. (каламбур не предназначен)

Answer 1

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

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

Answer 2

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

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

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

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

Update
В духе идти по пути производительности (например, ожидая, пока VS 2010 на самом деле), вы приняты меры, перечисленные в некоторых других вопросах переполнения стека: Very slow compile times on Visual Studio и Visual Studio Optimizations? Это может иметь большое значение и может обеспечить производительность до приемлемого уровня, в то время как мы wait on VS 2010 to ship.
еще несколько вещей, которые могут иметь хорошее влияние на производительность:

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

Answer 3

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

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

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

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

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

Answer 4

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

в верхней части window - это поле со списком, в котором вы можете выбрать конфигурацию Debug или Release build. Отбросьте это и выберите опцию «Configuration Manager ...».

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

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

Update: Для того, чтобы использовать NuGet мы добавили поддержку для создания nuspec файлы с автоматически определяемыми зависимостями.

Answer 7

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

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

Настоящий трюк заключается в том, чтобы включить «Load Dependencies» из пользовательского интерфейса vsFunnel. Когда вы открываете проект, он загружает все зависимые проекты и т. Д., Что значительно облегчает работу над целевым проектом.

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

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

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

Answer 8

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

ps. Я хотел бы знать, сделал ли кто-то сравнение Funnel vs. Solution Load Manger?