vb6 - Diagnosticando MSI autorreparable
windows-installer installer (2)
Su instalador está actuando en un directorio, archivo o clave de registro que Windows Installer sabe que es parte de la instalación de AutoCad.
Primero, activaría el registro global de Windows Installer. Esto significa que cualquier actividad de Windows Installer, incluido el instalador de AutoCad, se escribe en un archivo de registro externo (en% temp%).
A continuación, ejecute su instalador y deje que se ejecute el instalador de AutoCad.
Ahora ve a% temp% y deberías encontrar los archivos MSIXXXX.LOG - uno para tu instalador, uno para AutoCad. Ábralas y podrá abrirlas paso a paso e identificar qué archivo o clave de registro encuentra el AutoCad MSI que falta o ha cambiado.
Puede encontrar que WiLogUtl.exe es útil para esto:
Con un poco de suerte, identificará que el directorio, archivo o clave de registro que activa la reparación automática también está en su instalador. Si realmente está de suerte, puede identificarlo como un elemento que no debería instalar de todos modos, tal vez esté haciendo referencia a un componente del sistema que estaría presente de todos modos, algo protegido por la Protección de archivos de Windows.
De lo contrario, tendrá que mirar algo como RegFree COM para mover archivos de directorios compartidos a su directorio privado y reducir conflictos de registro. Además, si está utilizando (consumiendo) los MSM de Visual C ++ Runtime para hacer su MSI, considere usar el instalador de Microsoft EXE en su lugar o (lo mejor de todo) colocar los archivos DLL directamente en su carpeta de programa, ya que he encontrado que los MSM pueden causa solo este tipo de problema
La aplicación en la que trabajo está escrita principalmente en VB6.
Algunos usuarios informan que cuando inicien mi aplicación, se ejecutará automáticamente un instalador diferente de MSI e intentará reparar su propia instalación. A menudo esto es para AutoCAD pero a veces también para otros programas.
Por lo general, esto ocurre cada vez que inician la aplicación.
¿Qué procedimiento usamos para diagnosticar por qué ocurre esto? Dado que es el instalador de un tercero el que se está ejecutando, no tenemos visibilidad de lo que está haciendo.
AutoDesk tiene alguna información publicada sobre esto:
pero estos no brindan información suficiente directamente. Lo ideal es que pueda evitar por completo que esto ocurra a mis usuarios finales , en lugar de solo decirles cómo evitarlo o limpiarlo.
Con respecto al comentario de Peter Cooper Jr sobre VB6 que causa la auto reparación. Consulte la documentación de heat.exe para Wix. Verá que hay un cambio especial que la herramienta admite para suprimir la extracción de ciertos valores de registro que son propiedad del tiempo de ejecución de VB6 (y, por lo tanto, no debe ser alterado o actualizado por ningún otro MSI): http://wixtoolset.org /documentation/manual/v3/overview/heat.html
Vaya por la lista hasta el interruptor -svb6 y lea la descripción a la derecha. (Reproducido aquí :)
Al registrar un componente COM creado en VB6, agrega entradas de registro que son parte del componente de tiempo de ejecución VB6:
- CLSID {D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
- Typelib {EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
- Typelib {000204EF-0000-0000-C000-000000000046}
[así como] Cualquier interfaz que haga referencia a estas dos bibliotecas de tipos
¿Su instalador escribe en estas teclas? Si es así, trate de excluirlos; esto es bueno incluso si no es el culpable en este caso particular.
Aparte de eso, hay una larga descripción de lo que puede causar la reparación automática de Windows Installer aquí: ¿cómo puedo determinar qué causa la reparación automática repetida de Windows Installer? . Es un artículo extenso porque hay muchas maneras diferentes en las que se puede autorreparar. El denominador común es que diferentes instaladores en su sistema están peleando por una configuración compartida que continúan actualizando con sus propios valores en cada lanzamiento de la aplicación en un bucle sin fin.