В нашем программном обеспечении для обработки мы переходим от одной версии внешней сборки к более новой версии. Хотя общая задача, которую выполняет сборка, одинакова, API радикально отличается, и обратной совместимости не поддерживается. API отвечает за извлечение данных из внешних станций, которые могут работать с соответствующим новым или старым API (также без обратной совместимости). У нас нет контроля над программным обеспечением во внешней сборке или на внешних станциях. Внешняя сборка не имеет строгой подписи, и модуль в сборке имеет одинаковое имя для обеих версий.
Вместо того, чтобы поддерживать две версии нашего программного обеспечения для обработки, мы хотели бы динамически его развивать и использовать для связи либо старую версию, либо новую версию внешней сборки, зависящую от внешней станции. Мы можем определить, поддерживает ли внешняя станция новую версию, поэтому выбор «версии» может быть более или менее явным.
Итак, у нас есть внешняя сборка ComLib.dll в двух версиях. Можем ли мы сослаться на две версии одной и той же сборки / проекта и как мы можем различить две сборки при определении типов и т. Д.
Предполагая, что вышеупомянутое не может быть сделано из одной сборки / проекта, мы могли бы реализовать сборочные "адаптеры" для каждой версии, по одной для каждой версии внешней сборки (я думаю, у нас уже есть достаточно интерфейсов и абстракций для этого ) но есть ли какие-то предостережения, которые мы должны искать или какие-то конкретные настройки, чтобы избежать путаницы типа / версии во время выполнения (разрешение сборки / загрузка и т. д.)? Достаточно ли «параллельной» поддержки во время выполнения .NET для этой настройки?
ОБНОВЛЕНИЕ: добавлен еще один поворот в этом вопросе, просто чтобы сделать вещи более интересными. Кажется, что внешняя сборка загружает дополнительные сборки и использует внешние файлы конфигурации. Поскольку разные версии нуждаются в разных конфигурационных файлах и разных дополнительных сборках, каждая версия должна каким-то образом загружать дополнительные сборки, соответствующие их версии.
Мне кажется, что мы хотим, чтобы сборки из каждой версии загружались с «корнем» в отдельной папке, содержащей их файл конфигурации и дополнительные сборки. Возможно ли это даже со стандартным распознавателем / загрузчиком сборок, или нам нужно было бы сделать что-то волшебное и, возможно, загрузить сборки вручную (в отдельных доменах приложений?) Для принудительного применения «корневых» папок?