Лучший способ работать с несколькими проектами / решениями в Visual Studio? - PullRequest
23 голосов
/ 02 августа 2010

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

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

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

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

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

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

Ответы [ 3 ]

16 голосов
/ 02 августа 2010

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

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

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

10 голосов
/ 02 августа 2010
  1. Поместите общие коды в отдельный Solution / Project как библиотеку классов,
  2. В пост-сборке событий общих проектов скопируйте dll в определенный каталог,
  3. Добавьте общие dll из этого каталогадля других проектов / решений

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

3 голосов
/ 02 августа 2010

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

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

...