Объединение основных библиотек

Question

Около года назад наша компания выпустила относительно большой пакет программного обеспечения, написанный в основном двумя старшими разработчиками. Для удобства демонстрации я назову его «проект А». С тех пор мы работаем над новым программным пакетом «проект B», а его дерево является филиалом проекта A.

Проект B имеет ссылку на проект A, но теперь, когда мы приближаемся к концу проекта B, нам также нужно ссылаться на B от A. Итак, после слияния ветвей A и до того, как вы живете с B, мы хотели бы объединить основные библиотеки между этими двумя проектами.

Каковы некоторые переживания, которые у вас были с этим типом ситуации? Каковы некоторые лучшие практики и уроки, извлеченные в этом проекте? Как лучше всего объединить основные библиотеки с минимальным воздействием на остальную часть исходного кода в проекте A?

EDIT: Каково Ваше мнение о целесообразности сохранения пространств имен Проект A, но местонахождение кода в основной библиотеке Проект B (который в конечном счете станет основной библиотекой компании)? Оттуда просто обратитесь к новой библиотеке основной компании в устаревшие проекты ...

EDIT 2: Спасибо за ответы. Может быть, немного более техническое разъяснение в порядке. Оба эти проекта очень тесно связаны, но каждый из них имеет свой собственный проект библиотеки классов .NET для основной библиотеки. Кроме того, на каждую библиотеку ссылаются другие различные .NET-проекты; внутренние и внешние веб-приложения, приложения форм и т. д. Больше моего вопроса заключается в том, где должен жить исходный код - я не верю, что они должны оставаться двумя отдельными .NET-проектами, но в одном проекте содержатся оба, сохраняя существующие пространства имен изначально , По мере продолжения разработки мы будем реорганизовывать, комбинировать пространства имен, устранять дублирующиеся функциональные возможности и т. Д. Несомненно, функциональность, содержащаяся в обеих существующих библиотеках, будет полезна в будущих проектах, а также возникает необходимость делиться между существующими «основные» библиотеки.

Answer 1

Ваша проблема с возможностью циклических ссылок между B и A?

Или больше о конфликтующих пространствах имен между A и B.A?

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

Одна из возможностей - добавить префикс пространства имен в обе библиотеки, и в зависимости от того, какой вы хотите, вы можете импортировать его?

т.е.

А становится V1.A и BA становится V2.A (под проектом B)

Итак, если вы хотите V1 просто импортировать пространство имен V1, если вы хотите V2 импортирования V2 Я думаю, что пространство имен и ссылки должны совпадать?

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

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

Answer 2

Определяет, что это сильно зависит от языка, среды и типа библиотек (динамически/статически связанных). Какие проблемы вы ожидаете?

• сталкивающиеся идентификаторы
• дублируют функциональные
• изменения в процессе сборки
• интеграции/модульного тестирования