¿Cómo evito activar la auto reparación de MSI con mi paquete WiX/MSI?

windows-installer installshield (1)

Auto reparación, explicación simple y breve : ¿por qué el instalador MSI se reconfigura si elimino un archivo?

Breve resumen

Sigo intentando escribir sobre la repetición de la reparación automática de MSI para desarrolladores , pero termino con demasiados detalles. Aquí está mi último intento: consejos de diseño concretos sobre qué no hacer en su archivo WiX / MSI. Otros especialistas en implementación, extiendan la "lista de dificultades" a continuación.

Las respuestas anteriores que escribí resultaron ser relevantes para el desarrollador, pero no amigables para el desarrollador:

¿Cómo puedo determinar qué causa la reparación automática de Windows Installer? - Se enfoca en comprender el problema de auto reparación en general. Configuración del desarrollador / foco del empaquetador de aplicaciones.
¿Qué debo hacer al iniciar una aplicación que desencadena la reparación automática e infinita de Windows Installer? - Proporciona una lista de verificación para resolver escenarios de reparación automática. "Cómo arreglar el enfoque", en lugar de solo comprender. Para desarrolladores , administradores de sistemas , empaquetadores de aplicaciones y usuarios finales . Cómo manejar paquetes MSI defectuosos en general, de cualquier proveedor o fuente, no solo el suyo.

Creo que hay tiempo para otra perspectiva sobre la reparación automática. Ahora por fin puedo escribir lo que pretendía todo el tiempo: la visión del desarrollador de la reparación automática , algunas de las dificultades que deben evitarse para los desarrolladores que realizan su propio trabajo de desarrollo de configuración, a menudo utilizando el marco WiX . Solo una lista breve y concreta de cosas que no debes hacer en tu paquete MSI.

Problemas de diseño de MSI / WiX que causan problemas de auto reparación

Este es un primer borrador aproximado . Estas viñetas se desarrollarán cuando el tiempo lo permita.

Arruina la instalación de tiempos de ejecución compartidos . No utiliza módulos de fusión para implementar archivos de tiempo de ejecución compartidos o registrados globalmente. En su lugar, instale sus propias copias de los archivos y regístrelos en todo el sistema. Esto es particularmente malo para los archivos COM, pero también se aplica a otros tipos de archivos. Las aplicaciones en conflicto intentarán restablecer su estado, y los resultados de la "lucha de reparación automática" en cada lanzamiento alternativo de la aplicación.
Te encuentras con la peculiaridad de auto reparación de la carpeta vacía . Crea un componente vacío con una ruta de clave de directorio sin agregar una entrada CreateFolder. Esto provoca un bucle sin fin donde MSI elimina la carpeta y luego activa la reparación automática para volver a colocarla. Puede haber protección en WiX contra esto en este momento.
Recuento de referencias de componentes incorrecto . Usted mismo crea un conjunto de paquetes que instalan un archivo con el mismo nombre en la misma ubicación en el disco desde diferentes configuraciones de MSI utilizando diferentes GUID de componentes. Esto probablemente desencadenará la reparación automática a medida que los paquetes "luchen" para poner su versión del archivo en su lugar. Hay varias "soluciones" para esto, como el diseño de un módulo de fusión, el uso de un archivo de inclusión de WiX, la instalación del archivo sin conteo de referencias (guía de componentes en blanco) - (pronto se agregarán más detalles).
Instalación errónea de archivos por usuario . Instala archivos en el perfil de usuario y establece una ruta de clave de archivo en lugar de una ruta de clave de registro en HKCU (requerido por las pautas de diseño de MSI). Con frecuencia, esto hace que los usuarios habituales experimenten una reparación automática que nunca tiene éxito debido a la falta de permisos de disco. Los archivos de clave no son "vistos" por el usuario normal porque no hay permiso de lectura donde reside el archivo de clave (perfil de usuario de otro usuario). Aquí hay una ilustración en color .
Permisos personalizados de disco / registro erróneos . Este problema es diferente, pero similar al problema anterior. Aplica permisos personalizados de archivo, carpeta y registro durante la instalación que elimina el acceso de lectura a las ubicaciones de instalación para los usuarios habituales. Los usuarios habituales verán la reparación automática que nunca tiene éxito. Esto también puede suceder con las ubicaciones de archivos "por máquina", no solo con las rutas de perfil de usuario (como en el número anterior). Escucho rumores de que algunos han visto esto en particular también para archivos ini protegidos contra escritura.
Deja el recuento habilitado para los archivos temporales . Por alguna extraña razón, decide instalar un archivo en la carpeta tmp u otra carpeta que pueda limpiarse en cualquier momento. Quizás tenga la intención de ejecutar el archivo desde una acción personalizada o algo así. En cualquier caso, lo instala a través de un componente con un guid de componente y un conjunto de ruta de clave, y cuando el archivo se "limpia" del disco, su archivo MSI intentará volver a colocarlo. Esto se repite cada vez que el archivo se "limpia". Dado que la ubicación de instalación es probable que sea una ubicación por usuario, es posible que otros usuarios no "vean" el archivo desde su inicio de sesión y experimenten una reparación automática y repetida, mientras que solo lo verá cuando el archivo esté "limpio".
Malware: positivos reales y falsos . Instala un binario inusual sin ejecutarlo a través de una detección básica de virus / malware. Es tan importante verificar si hay malware real como lo es para detectar falsos positivos (un servicio de escaneo de malware para usar es http://www.virustotal.com - casi 70 escáneres diferentes - preste especial atención a los principales proveedores - obviamente) . Por lo tanto, ignora la comprobación de malware y, después de la implementación, su producto sufre falsos positivos de varios proveedores de antivirus y la reparación automática se ejecutará en vano tratando de volver a colocar el archivo para "ponerlo en cuarentena" nuevamente . Tus clientes te culpan. El resultado es, por supuesto, igualmente malo si realmente instala un virus o malware real. El resultado es exactamente el mismo: la reparación automática sigue funcionando en vano. Por otro lado, si el binario se infectó después de la instalación, la reparación automática debe cumplir su propósito y ejecutarse una vez para volver a colocar el archivo limpio en su lugar. El principal problema es que corregir un falso positivo es en realidad más difícil que lidiar con malware (el malware es, por supuesto, peor para el cliente si causa pérdida de datos, pero se entiende que esto está fuera de sus manos como proveedor de software). Con el malware, simplemente le dice a su cliente que reconstruya sus PC y reinstale su software, pero con un falso positivo necesita hacer algo para incluir su binario en la lista blanca , a menudo con varios proveedores de software de seguridad. ¿Cómo manejas este proceso? A medida que el malware parece empeorar y empeorar la seguridad de cualquier manera posible, es probable que los falsos positivos se conviertan en un gran problema de implementación, incluso más que ahora. Se puede perder mucho tiempo tratando de obtener su lista blanca binaria . Y lo obvio, pero digámoslo en voz alta: no desafíe esta tarea por su cuenta como persona de implementación; esta lista blanca es una tarea enorme que requiere la participación de la administración. El problema afecta todo para un proveedor de software: ventas, desarrollo, marketing y soporte. A medida que el software de seguridad se vuelve más avanzado e "inteligente", pueden comenzar a poner en cuarentena todo el MSI en caché en el sistema que se encuentra en %SystemRoot%/Installer (utilizado para instalaciones de mantenimiento, reparación y desinstalación). Cuando esto suceda, no será posible la reparación automática, y tampoco la desinstalación (!), A menos que tenga acceso al MSI original exacto que se utilizó para instalar. En estos casos, supongo que podría probar algunas de las opciones enumeradas aquí para desinstalar su MSI con malware o falsos positivos: ¿Por qué MSI requiere el archivo .msi original para proceder con la desinstalación? o la sección 12 aquí: Desinstalar un archivo MSI desde la línea de comandos sin usar msiexec .
Instala archivos de escritorio que el usuario puede eliminar . Este es un "caso marginal" que requiere que también haya configurado erróneamente la ruta clave para el componente de instalación en una ruta clave de disco (en lugar de la ruta HKCU correcta). La mayoría de las veces coloca accesos directos en el escritorio, y esto está bien. Sin embargo, si instala un archivo de datos de algún tipo que el usuario luego elimina, podría verlo reestablecido por la reparación automática cuando su aplicación se inicia a través de un acceso directo anunciado, o incluso si se crea una instancia de un objeto COM anunciado o un tipo de archivo particular es lanzado.
Instala accesos directos anunciados a la carpeta "Inicio" . No instale accesos directos anunciados en la carpeta "Inicio". Puede activar la reparación automática para que se ejecute en cada inicio del sistema sin que tenga lugar ninguna interacción del usuario. Se ha informado que eliminar el acceso directo también desencadena la reparación automática. Esto es algo que nunca he visto, pero tiene sentido.
Utiliza una ruta de clave HKCU (o HKLM para el caso) que cambia su aplicación . Cualquier configuración que escriba desde su MSI en el registro generalmente no debe ser modificada, o peor aún, eliminada por la operación de su aplicación. Es probable que se produzca una reparación automática. Solo escriba datos que la aplicación solo lea. Su propia aplicación siempre debe completar todas las configuraciones predeterminadas en HKCU, y su configuración nunca debe interferir con ellas. Lo mismo ocurre con los archivos de perfil de usuario. Deben copiarse para cada usuario desde una ubicación de plantilla por máquina. La moraleja general de la historia: implementar solo archivos y configuraciones por máquina (HKLM). La aplicación debe inicializar todo lo demás: ¿por qué es una buena idea limitar la implementación de archivos en el perfil de usuario o HKCU cuando se usa MSI? .
Su configuración escribe en las claves de registro que se sobrescriben periódicamente por la política de grupo . Creo que vi este problema por primera vez en relación con algunas claves de configuración de proxy IE en HKCU que se configuran usando un MSI. Usar un MSI para configurar algunas claves de registro siempre es una mala idea por muchas razones. Consulte esta respuesta de serverfault.com para obtener una lista de varios problemas: paquete MSI para la implementación de registros (lectura rápida recomendada, aunque es más relevante para los administradores del sistema, pero es importante saberlo para los desarrolladores). Tengo problemas para reproducir este problema, ya que la reparación automática se activa cuando faltan las rutas clave (generalmente no solo se cambian o modifican). ¿Quizás la política de grupo realmente eliminó los valores HKCU que fueron agregados por el MSI? Vimos el problema, así que esto es probablemente lo que sucedió. El mensaje general : nunca use un MSI para establecer solo algunas claves de registro, particularmente si están en HKCU. Use políticas de grupo, secuencias de comandos de inicio de sesión, secuencias de comandos VB, PowerShell u otras medidas más confiables, como hacer que las aplicaciones lo hagan en el inicio (una vez por usuario).
Usted registra un archivo / asociación MIME particular o un verbo de comando en su archivo MSI . La mayor parte de la reparación automática parece ser provocada por la interferencia del registro COM entre productos que desencadena la reparación automática en la creación de instancias de objetos COM, o la invocación de un acceso directo anunciado. Sin embargo, también puede activar la reparación automática a través de asociaciones de archivos / MIME y verbos de comandos. En particular, las asociaciones de archivos podrían ser registradas por otras aplicaciones / archivos MSI en el sistema, y esto podría desencadenar una reparación automática muy persistente ya que cada aplicación intenta "recuperar" la asociación de archivos. Use estas funciones con moderación en su MSI y asegúrese de que las asociaciones de archivos que registre sean realmente únicas. Nunca establezca una asociación de archivo "común" en su configuración de MSI (por ejemplo, jpg).
El mismo MSI se instala dos veces (o más) por error. Esto suena extraño, pero en realidad es posible de varias maneras. La reparación automática podría no ser su mayor problema si esto sucede, también verá otros problemas:
- Olvida generar un nuevo GUID de paquete para su MSI reconstruido. Windows Installer trata los dos archivos MSI diferentes como el mismo archivo "por definición". Creo que he visto una reparación automática en estos casos, pero también se enfrentarán a una gran cantidad de otros problemas, todos igualmente extraños. Genere siempre automáticamente el GUID del paquete. No hay ninguna razón para que dos archivos MSI tengan el mismo GUID de paquete (a menos que esté probando algo increíblemente oscuro en el motor de Windows Installer). Si bien es plenamente consciente del problema de los GUID duplicados, hace muchos años me sucedió el uso de Installshield durante un desarrollo muy agitado. Todavía me pregunto cómo sucedió realmente, pero sucedió. Tal vez fue un error desconocido en la herramienta?
- Una actualización importante fallida puede dejar dos versiones de su instalación instaladas al mismo tiempo. Verá dos entradas en Agregar / quitar programas. Los problemas de auto reparación son posibles en estos casos, pero también lo son una gran cantidad de otros problemas. En mi experiencia, este problema es grave, pero no tan malo como usar el mismo GUID de paquete para dos archivos MSI (punto anterior).
- Estoy seguro de que hay varias otras formas en que el mismo producto puede terminar instalándose varias veces. ¿Quizás las transformaciones fallidas de varias instancias también pueden causar el problema? No me gusta ese concepto en particular, así que realmente no lo he intentado.

Algunos problemas generales relacionados con la reparación automática de "finalistas":

Ejecute la validación en su MSI y varios de los problemas anteriores se marcarán y se eliminarán fácilmente.
Nunca ejecute MsiZap.exe en su caja de desarrollador o cualquier máquina que no pueda revertir fácilmente. De hecho, no use esta "herramienta" en absoluto. A menudo verá problemas de reparación automática cuando se implemente sobre el "estado sucio" creado por el nukeo MsiZap.exe de la base de datos MSI.
Si necesita instalar extensiones de shell COM, asegúrese de realizar una prueba exhaustiva cuando use el Explorador de Windows y cambie entre los diferentes modos de vista para verificar si se inicia la reparación automática. Un objeto COM como este está esencialmente en uso continuo y, por lo tanto, la reparación automática muy probable (cierto) si se interfiere con alguna configuración.
Si coloca un acceso directo anunciado en una función por sí mismo, casi nunca debería desencadenarse una reparación automática. La verificación de la ruta de acceso clave se realiza para la función en la que se encuentra el acceso directo y para todas sus funciones principales (la última vez que revisé ;-), que fue hace años).

Consejos generales de WiX / MSI

Esta sección creció demasiado y contenía demasiadas cosas no relacionadas con problemas de auto reparación. Lo puse en su propio artículo: ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI?

Respuestas relacionadas con la reparación automática (enlaces para la custodia):

¿Cómo evito activar la reparación automática de mi paquete MSI generado por WiX?

Esta es una pregunta de estilo Q / A con una respuesta que solo enumera algunas cosas que no debes hacer en tu archivo MSI para evitar las causas más comunes de repetir la auto reparación.