Должен ли проект Visual Studio содержать более одного решения?

Примечание. Это для магазина, который работает на С++, С++/CLI и С#, а некоторые продукты поставляются в виде комбинации из всех трех.

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

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

У нас довольно много кода в библиотеках, dll и сборках, которые потребляются множеством поставляемых продуктов, и в настоящее время мы контролируем это с помощью системы управления зависимостями между решениями, в результате чего, если вы работаете в решении для конца -product, просто запросить сборку зависимых решений, которая запускает другие экземпляры Visual Studio для их создания. Система работает, но имеет следующие недостатки:

Решения для общих проектов часто бывают слишком жирными, что содержит несколько проектов, необходимых для разрабатываемого продукта и обычно намного больше, которые не нужны для разработки. Они просто были объединены в своеобразное решение, которое охватывает все проекты, которые просто связаны друг с другом. Это приводит к увеличению времени сборки из-за компиляции ненужного кода.
В тех случаях, когда мы пытались решить вышеуказанные жирные решения, мы часто оставляем слишком тощее решение, которое содержит только один проект. Для каждого из них требуется дополнительная конфигурация в системе управления зависимостями между решениями. Это также может увеличить время сборки, поскольку несколько экземпляров Visual Studio развернуты.

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

Разве большое количество проектов в одном решении создает проблемы стабильности в Visual Studio 2005 (наша текущая платформа разработки)? Получается ли он лучше в VS 2008 или VS 2010?
Если проект содержится в нескольких решениях, как можно управлять эффектами для нескольких решений, следует ли модифицировать конфигурации проекта (например, добавить новую конфигурацию)?

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

Ответ 1

Нет, используйте как можно больше решений.

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

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

изменить

Чтобы ответить на последнюю часть вашего вопроса (потому что SO убирает вопрос, пока вы редактируете ответ!), единственная проблема с решениями в VS2005 заключается в том, что он очень медленный с большим количеством проектов в них. VS2008 намного быстрее при загрузке большого решения, но главный удар заключается в том, что чем больше проектов есть в решении, тем дольше он требуется для создания (даже если он просто пропускает проекты, которые не нужно строить, это занимает много времени)

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

Ответ 2

Основные проблемы с одним проектом в нескольких решениях:

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

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

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

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

Количество проектов в решении не является серьезной проблемой. Но это замедлит процесс растворения для загрузки и сборки. У нас есть решения более чем 50 проектов.

Ответ 3

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

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

Ответ 4

У нас есть "главное решение", которое содержит более 100 проектов. Это потребовалось навсегда для загрузки на VS.2005, пока Microsoft не выпустила исправления Intellisense, описанные здесь здесь.

Наша автоматизированная процедура построения "непрерывной интеграции" всегда создает главное решение. Для разработки я разделяю "основное решение" на более мелкие решения, которые содержат подмножество связанных проектов. Поддержание этой структуры занимает некоторое время, когда новые проекты добавляются, но это того стоит.

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

Ответ 5

Инструменты для файла SLN (файл решения Visual Studio) содержит инструмент, который:

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

Это удаляет значительную часть стоимости поддержки файлов файлов подмножества для скорости разработки.

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

Ответ 6

Теперь есть свободное расширение Visual Studio, "Funnel" , которое решает эту проблему, загружая предопределенные подмножества решение. Ссылка на VS2012-VS2015; есть также версия VS2010, на которую ссылаются на домашней странице расширения.

Вы можете настроить несколько профилей (т.е. сочетания проектов). Они хранятся в параллельном файле solution.sln.vsext, и этот файл может быть передан и передан вашей команде. В то время как VS2015 стал намного лучше справляться с большими проектами на 100+ C/С++/С#, я считаю это особенно полезным для исключения проектов make файлов, которые создаются каждый раз при построении решения.