Используя WiX для установки Двоичных файлов VB6
Я преобразовываю проект InstallShield в основанный на WiX Установщик. У меня есть много проектов VB6, двоичные файлы которых должны быть зарегистрированы.
Проект InstallShield на самом деле отмечает их как саморегистрирующиеся файлы. Из того, что я читал, это, кажется, "Плохая Вещь" в мире Windows Installer.
Мой вопрос, что я должен делать затем? Проект VB6 мог иметь свое внутреннее изменение GUID после того, как каждый перекомпилировал - и да я уже использую Совместимость на уровне двоичных кодов.
Я использовал Тепло для генерации всех записей Реестра и Класса, но некоторые из этих записей изменяются от сборки до сборки. Я читал, то Тепло не было разработано, чтобы использоваться каждая сборка, но вместо этого использоваться в качестве начальной точки.
Что другие делают для контакта с регистрацией WiX и VB6?
3 ответа
Одна вещь, над которой мы играем, - это полное устранение глобальной регистрации COM с помощью COM без регистрации . (Основное преимущество, которое нам нужно, - это возможность развертывать разные версии одного и того же приложения бок о бок в полной изоляции.)
Однако с COM без регистрации вам все равно придется писать или генерировать файлы манифеста, которые должны быть развернуты установкой. Ответы на связанный вопрос показывают, что есть некоторые инструменты, которые помогут в этом.
Между тем, мы также по-прежнему используем сочетание саморегистрации и автоматического создания wxs с помощью heat.exe для наших старых библиотек VB6 и Delphi. Хотя вы правы в том, что тепло изначально не предназначалось для такого использования, оно уже некоторое время движется в этом направлении .
В любом случае стабильная регенерация идентификаторов (которая отсутствовала в первоначальном дизайне heat.exe) важна только в том случае, если вы хотите поддерживать незначительные обновления или совместно использовать компоненты между приложениями. Мы просто полностью удаляем предыдущую версию продукта во время обновления (также известного серьезное обновление ), поэтому нам не нужно беспокоиться о таких вещах.
edit : С момента написания этого ответа в 2010 году я кое-что узнал об установщике Windows. Я больше не верю, что серьезное обновление избавит вас от необходимости в стабильных идентификаторах GUID. Идентификаторы GUID компонентов должны оставаться максимально стабильными между обновлениями на месте. Основные обновления не всегда имеют такой же конечный результат, как удаление + повторная установка.
У нас есть два типа компонентов, которые мы разрабатываем на VB6. Скрытые общие компоненты, на которые мы ссылаемся в проектах, и изменчивые компоненты приложений, которые мы создаем ежедневно. Общие компоненты упакованы как модули слияния (с использованием WiX), в то время как компоненты приложения сопоставляются с компонентами настройки приложения. Это фрагмент нашего основного файла .wxs
<Component Id="MyFile15.ocx" Guid="YOURGUID-BCB7-451C-B07D-D205AEAE1EB9" >
<File Id="MyFile15.ocx" Name="MyFile15.ocx" LongName="MyFile15.ocx" KeyPath="yes" src="$(var.SrcAppBinnPath)\MyFile15.ocx" DiskId="1" />
<?include Registry_MyFile15.wxi ?>
</Component>
. Мы все еще используем WiX 2.0, поэтому мы используем измененную версию tallow для создания файлов .wxi реестра для всех ActiveX DLL / OCX / EXE мы создаем ежедневно. Вместо записей com / typelib мы отправляем всю регистрацию COM в виде прямых записей таблицы реестра. Мы ориентируемся на устаревший установщик Windows 2.0, потому что нам не нужны никакие новые функции.
Мы используем специальные действия (библиотеки DLL VC6) для некоторых особых случаев - установка MSDE, исправление базы данных, загрузка / установка DCOM. Мы используем загрузчик Platform SDK, который загружает instmsiX.exe и подготавливает установщик Windows в исходных системах (в основном 9x и NT). Мы используем самораспаковывающийся 7-zip для распаковки загрузчика и msi на клиентской машине.В некоторых случаях мы используем UPX --lzma для исполняемых файлов, но они не очень хорошо масштабируются на терминальных серверах, где неупакованные версии повторно используются в сеансах.
В последнее время мы переводим наших клиентов на переносимые сборки, используя COM без регистрации. Мы используем наш собственный инструмент UMMM для создания манифестов COM без регистрации. SxS COM имеет ограничения (нет DCOM, нет ActiveX EXE), но позволяет нам изменять сборки во время работы приложения - без простоев при переустановке.
Я пошел другим путем и определил все свои объекты, используя интерфейсы, которые я создал в IDL и скомпилировал в библиотеки типов (.tlb). Немного затянутый подход, но это означает, что все идентификаторы GUID остаются фиксированными независимо от того.
Я могу внедрять версии интерфейсов и обрабатывать несколько версий dll в одном файле.
Недостатки в том, что это не помогает с элементами управления OCX, и вы не можете использовать события, выходящие за границу tlb. Для меня это не проблема, поскольку я обычно использую обратные вызовы из DLL для их вызывающих, поскольку они могут быть более эффективными.
Этот продукт развернут на DVD для клиентов по всему миру, в настоящее время использующих установщик InstallShield, но я также планирую перейти на WiX.