Когда я должен добавить проект в свое решение по сравнению с добавлением dll проекта в мое решение

Question

Итак, сейчас у меня есть проект A и проект B. Затем есть проект библиотеки классов Z. Проект Z содержит классы и методы, используемые как A, так и B.

У меня вопрос, должен ли я скомпилировать проект Z и добавить его в проект A и B, используя его dll, или добавить сам проект к A и B?

В каких случаях я буду использовать проект в проекте в dll в проекте?

Answer 1

Если код из проекта Z построен и выпущен по тому же графику, что и проекты A и B, Z, вероятно, должен быть частью того же решения.

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

Вы можете задать себе простые вопросы, например, должен ли Z компилироваться каждый разА и Б компилируются?Должен ли разработчик, работающий над A и B, изменить Z?

Answer 2

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

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

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

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

Answer 3

Я далеко не эксперт в этом, но мое общее правило:

• Если A и B тесно связаны и Z существует главным образом для их поддержки, пусть A и B используют ссылку на проект Z.
• Если A и B не тесно связаны, Z был создан для поддержки A, а затем признан полезным для B, пусть A использует ссылку на Z-проект, а B использует ссылку на Z dll.
• Если Z был создан как отдельная библиотека, предназначенная для использования всеми без исключения проектами, которые могут оказаться полезными, все используют ссылку на Zll.

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

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

Answer 4

Я думаю, что если Z используется как A, так и B (при условии, что A и B находятся в разных решениях), то вы должны добавить Z как dll.Таким образом, вы будете редактировать код в одном месте вместо двух, и вы уверены, что A и B используют одну и ту же версию библиотеки Z (снова предположим, что вы обновляете dll в обоих;))

Answer 5

Я бы предложил ветвь Z с вашей системой контроля версий и добавить ее в качестве проекта.Таким образом, вы получаете лучшее из обоих.Вы получаете полную отладку и можете редактировать библиотеку, и ваши проекты A и B не пострадают, если интерфейс Z обновлен в других решениях.

Если вы делаете обновления для Z, вы можете объединить их с другими версиямиконтролируемым образом.

Если Z не очень хорошо документирован, вы определенно хотели бы перемещаться по Z-коду и выходить из него при кодировании на A и B.

Только если Z велико и принимаетЧтобы перекомпилировать, я предпочитаю включать его в виде DLL.