Развертывание COM DLL, которые используются несколькими продуктами / версиями

Question

Допустим, у вас есть два продукта A и B, которые одновременно разработаны, протестированы и выпущены одной и той же компанией.В интересах повторного использования кода и не выполнения работы дважды создается третья ветвь управления исходным кодом, C, где размещается низкоуровневый код утилиты / фреймворка / помощника.Этот код включает в себя некоторые COM-библиотеки.

Затем руководство решает, что A и B действительно должны иметь свои собственные циклы выпуска и управляться как полностью отдельные продукты.Теперь вы не можете изменять / обновлять C в любое время, когда захотите, потому что когда одна команда работает над A, другая команда может выпустить B через 2 недели, поэтому любой код, входящий в B (включая C), должен быть заморожен.

Решение, которое я вижу, состоит в том, чтобы вынуть C и сделать его отдельным SDK, от которого будут зависеть и A, и B.Этот SDK будет иметь собственную схему управления версиями и собственный цикл выпуска.Таким образом, A может взять на себя обязательство использовать C-1.2.4, и если B требуется что-то более новое, он может внести изменения в C-1.3.8

Проблема, которую я сейчас пытаюсь решить, состоит в том, как обрабатывать COM-библиотекичто может быть возможно, что и A, и B могут быть установлены на одном компьютере.Я вижу три варианта, но не уверен, какой из них хорош / лучше, или если есть еще один вариант, которого я не вижу:

1. Каждый раз, когда меняется номер версии, нужно, чтобы какой-то скрипт просматривал файлы .IDLи измените все идентификаторы GUID.Может работать, но по некоторым причинам многим людям кажется страшным (включая меня)
2. Использовать COM-активацию без регистрации.Будет ли это работать с исполняемыми файлами не под нашим контролем?(graphedt.exe, iexplore.exe ...).
3. Убедитесь, что все COM-объекты, идущие вперед, имеют обратную совместимость и что и A, и B используют последнюю версию установленных модулей.Это похоже на ночной кошмар тестирования, потому что в конечном итоге мы получим комбинации компьютеров и DLL, которые не были проверены на соответствие требованиям.

Answer 1

Прошло много времени с тех пор, как я присматривал за сборкой или выпуском, но я хорошо помню DLL HELL! У вас есть мои симпатии!

Как вы уже сказали, чтобы создать общую установку - установите ее в C: \ Program Files \ Common Files \ YourProductOrCompany \ Version и зарегистрируйте их. вам нужно будет поддерживать обратную совместимость и корректно использовать версию MSI (при условии, что вы используете ее). Таким образом, каждая установка может установить общий пакет, если он имеет большую версию.

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

И наступили моменты, когда изменения были признаны значительными, и была изменена версия общего компонента (включая все ClassID и т. Д.). Таким образом, вы можете использовать 10.1 и 11.1 на одной машине с разными ядрами.

НТН, Matt