Лучшая практика для совместного использования общих библиотек между решениями в .NET

Question

У нас есть пул решений MSVS (решение «A», «B», «C», ...), которые совместно используют базовую функциональность в сборке под названием «Common.dll».

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

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

A). Поместите исходный код common.dll в каждое решение . Плюсы: это поможет активным решениям расти вместе с common.dll, в то время как пассивные решения будут компилируемыми. Минусы: трудно синхронизировать активный код common.dll между активными решениями

В). Поместите двоичный код common.dll в каждое решение . Плюсы: все проекты будут скомпилированы, а код common.dll будет централизован. Минусы: сложно вырастить активные решения параллельно с common.dll

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

D). ?

Заранее спасибо!

Answer 1

Существуют и другие варианты, а также:

D) Поместить все проекты в один корень SVN (или другого CVS).

Это позволяет выполнять ветвление и пометку, покаубедившись, что у вас есть согласованная версия Common с каждым проектом.Таким образом, вы просто включаете проект в каждое решение по мере необходимости.

Проблема, конечно, в том, что все проекты находятся в одном SVN.:)

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

E) Использовать внешние SVN

Если вы используете Subversion, вы можете использовать SVN Externals (сопоставление локальной подпапки с URL версионного ресурса).GIT также поддерживает что-то похожее , но это немного сложно, если вы хотите отправить изменения во внешние репозитории.

Answer 2

Я бы сразу сказал скидку (A), так как вы убьете любую способность, которую вы имеете для удобства обслуживания!

Фактически, все сводится к тому, как часто эти базы кода будут меняться.

Наше настоящее решение для аналогичной установки, над которой я работаю, состоит в том, чтобы иметь отдельный проект Common, и двоичные файлы копируются в папку «Libs» для каждого Проекта, который ссылается на Common. Причина этого заключается в том, что у нас есть возможность развернуть явные версии common.dll для каждого проекта. Папка Libs поддерживается через TFS. Таким образом, хотя родительский проект не нужно перекомпилировать, TFS увидит новую регистрацию и сможет действовать соответствующим образом.

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

Answer 3

Мы практикуем что-то вроде B.

CI-сервер обеспечивает постоянную актуальность общих библиотек (даже если они сами используют другие общие библиотеки).Каждое решение, использующее общие библиотеки, имеет папку «Lib», в которую мы помещаем артефакты сборки, но они не находятся под контролем исходного кода (в отличие от внешних артефактов, таких как импортированные через NuGet).

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

Сервер CI всегда будет копировать последние общие библиотеки в «Lib» строящегося решения, чтобы интегрировать последние общие библиотеки.Если нам нужно создать сборку со старыми библиотеками (конкретный выпуск исправлений - очень редко), мы всегда можем использовать артефакты сборки с соответствующей датой.Обычные выпуски исправлений / исправлений, как правило, также обновляются до последних общих библиотек.