Лучший способ работы с несколькими проектами/решениями в Visual Studio?

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

На данный момент это всего лишь несколько форм и связанный с ними код.

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

Я посмотрел на создание нового проекта в одном из решений библиотеки .dll/class, но я чувствовал, что это неверно. (Скажите, если я ошибаюсь).

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

Можно ли включить это решение в другие, если мне нужно сделать простое изменение и обновить его во всех проектах или вместо этого, должен ли я всегда работать с общим компонентом в отдельном экземпляре Visual Studio, вне приложений, использующих его?

Ответ 1

Это точно правильный способ справиться с этой ситуацией.

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

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

Ответ 2

Поместите общие коды в отдельное решение/проект как библиотеку классов,
В событии пост-сборки общих проектов копия dll в конкретный каталог
Добавить общую dll из этого каталога в другие проекты/решения.

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

Ответ 3

Перемещение общего кода в отдельную общую сборку является отличным вариантом.

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