Какой тип визуального решения для студии мне подходит?

Question

В настоящее время у меня есть программа, которую я написал, которая разделена на 3 отдельных решения.

1. Внешний интерфейс (все, что связано с дисплеем)
2. Парсеры (несколько (39) проектов, каждый из которых создает DLL для анализа определенных данных)
3. Globals (несколько (5) проектов, каждый из которых создает dll, который используется проектами в решении парсеров и внешним интерфейсом).

Требования -

• И интерфейс, и анализаторы требуют, чтобы глобальные библиотеки существовали во время компиляции и использовались во время выполнения.
• Библиотеки парсеров загружаются во время выполнения с использованием assembly.LoadReference.
• Разработка: C:\projects\myProg
• развернутое местоположение: C:\myProg

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

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

Answer 1

Добавьте все проекты в одно решение.

Измените любые ссылки между проектами на "ссылки на проекты", а не прямые ссылки на файлы DLL. Это исправит множество проблем с зависимостями.

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

Наконец, рассмотрите возможность объединения многих ваших проектов в один проект / сборку. Убийство времени сборки - это не количество кода, а количество сборок - на моем ПК каждый проект добавляет довольно постоянные 3 секунды ко времени сборки, поэтому, объединяя небольшие проекты, я сэкономил немало времени на сборку.

Answer 2

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

ПРИМЕЧАНИЕ: Вам не нужно ничего перемещать из их текущего местоположения.

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

Текущие («старые») решения также будут доступны, как и они.

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

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

Answer 3

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

Управление зависимостями в Visual Studio стало проще:

• Щелкните правой кнопкой мыши узел решения

• Выберите «Порядок сборки проекта ...»

Убедитесь, что для каждого проекта в этом диалоговом окне не нужен проект под ним.

По поводу "где развернуть": по умолчанию Visual Studio делает это хорошо. Если вы находитесь в режиме отладки, он выведет в папку отладки вашего решения, также для выпуска.

НТН.

Answer 4

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