Usando WiX para instalar Binarios VB6

Question

Estoy convirtiendo un proyecto InstallShield en un instalador basado en WiX . Tengo varios proyectos de VB6 cuyos binarios deben registrarse.

El proyecto InstallShield realmente los marca como archivos de autorregistro. Por lo que he leído, esto parece ser una "mala cosa" en el mundo de Windows Installer.

Mi pregunta es, ¿qué debería estar haciendo entonces? Un proyecto VB6 podría tener sus GUID internos cambiar después de cada recompilación, y sí, ya estoy usando la compatibilidad binaria.

He usado Heat para generar todas las entradas de Registro y Clase, pero algunas de estas entradas cambian de una compilación a otra. He leído que Heat no fue diseñado para usarse en cada construcción, sino que debe usarse como punto de partida.

¿Qué están haciendo otros para lidiar con el registro de VB6 y WiX?

Answer 1

Tenemos dos tipos de componentes que desarrollamos en VB6. Componentes comunes latentes a los que hacemos referencia en los proyectos y componentes de aplicaciones volátiles que construimos a diario. Los componentes comunes se empaquetan como módulos de combinación (usando WiX) mientras que los componentes de la aplicación se asignan a los componentes de la configuración de la aplicación. Este es un fragmento de nuestro archivo principal .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>

Todavía estamos usando WiX 2.0, así que estamos usando una versión modificada de sebo para producir los archivos .wxi de registro para todos los archivos DLL / OCX / EXE de ActiveX que estamos creando diariamente. En lugar de las entradas com / typelib, enviamos todo el registro COM como entradas de tabla de registro directo. Nuestro objetivo es Windows Installer 2.0 heredado porque no necesitamos ninguna de las funciones más nuevas.

Estamos utilizando acciones personalizadas (DLL VC6) para algunos casos especiales: instalación de MSDE, parcheo de base de datos, descarga / configuración de DCOM. Estamos utilizando un bootstrapper Platform SDK que descarga instmsiX.exe y prepara Windows Installer en sistemas vírgenes (principalmente 9x y NTs). Estamos utilizando el autoextractor 7-zip para desempaquetar bootstrapper y msi en la máquina del cliente. En algunos casos estamos usando UPX - lzma en ejecutables, pero estos no se escalan muy bien en los servidores de terminales donde las versiones no empaquetadas se reutilizan en todas las sesiones.

Últimamente hemos estado migrando a nuestros clientes a compilaciones portátiles utilizando COM sin registro. Estamos utilizando nuestra herramienta UMMM interna para producir manifiestos COM sin registro. SxS COM tiene limitaciones (sin DCOM, sin EXEs de ActiveX) pero nos permite cambiar las compilaciones mientras la aplicación está activa, sin reinstalar el tiempo de inactividad.

Answer 2

Seguí una ruta diferente y definí todos mis objetos usando las interfaces que creé en IDL y compilé para escribir bibliotecas (.tlb). Un enfoque un poco largo sin aliento, pero significa que todos los GUID permanecen fijos independientemente.

Puedo implementar versiones de las interfaces y manejar múltiples versiones de la dll en el mismo archivo.

Los inconvenientes son que esto no ayuda con los controles OCX y no puede usar eventos según el límite tlb. Esto no es un problema para mí, ya que generalmente utilizo devoluciones de llamadas de DLL a sus interlocutores, ya que pueden ser más eficientes.

Este producto se implementa en DVD para clientes de todo el mundo, que actualmente usan un instalador de InstallShield, pero estoy investigando el traslado a WiX también.

Answer 3

Una cosa con la que hemos estado jugando es eliminar completamente el registro COM global mediante el uso de COM sin registro . (La principal ventaja que perseguimos es la capacidad de implementar diferentes versiones de la misma aplicación una al lado de la otra en completo aislamiento).

Sin embargo, con el COM sin registro, usted todavía tiene que escribir o generar los archivos de manifiesto que la instalación debe implementar. Las respuestas a la pregunta vinculada muestran que hay algunas herramientas para ayudar con eso.

Mientras tanto, también usamos una combinación de autorregistro y generación automática de wxs con heat.exe para nuestras antiguas bibliotecas VB6 y Delphi. Si bien tienes razón de que el calor no fue diseñado inicialmente para ser usado así, hace un tiempo que se mueve en esa dirección .

En cualquier caso, la regeneración estable de identificadores (que es lo que faltaba en el diseño inicial de heat.exe) solo es importante si desea admitir actualizaciones menores o compartir componentes entre aplicaciones. Simplemente desinstalamos por completo la versión anterior del producto durante una actualización (también conocida como una actualización importante ), por lo que no tenemos que preocuparnos por tales cosas.