¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI?

¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI?


La implementación es una parte crucial de la mayoría del desarrollo: la implementación fallida significa que su usuario final nunca podrá evaluar su producto. Este podría ser fácilmente el error más caro en el desarrollo de software . Por favor dale una oportunidad a este contenido. Tengo la firme convicción de que la calidad del software se puede mejorar de manera espectacular mediante pequeños cambios en el diseño de la aplicación para hacer que la implementación sea más lógica y más confiable; de ​​eso se trata esta “respuesta”: desarrollo de software .


Esta es una pregunta al estilo de Q / A con una respuesta que solo enumera algunas cosas que no debes hacer en tu archivo MSI para evitar los defectos de diseño más comunes.

Anti-Patrones de Implementación WiX / MSI

Existen varios patrones de despliegue que a menudo se ven en los archivos de WiX / MSI . A continuación se muestra un borrador de algunos de los más comunes.

¡Antes de entrar en los problemas, por otro lado, aquí hay un recordatorio rápido de las cosas que han hecho que MSI sea un éxito rotundo! (a pesar de sus problemas).

Esta respuesta es un trabajo en progreso

¿Qué sabes? Aprovecho el tamaño máximo para la respuesta. Supongo que es una pista ya es suficiente :-). Sin embargo, algunas secciones necesitan aclaración y mejora.

Si reconoce algunos de estos problemas, es posible que desee seguir leyendo ; estos son odios y molestias conocidos del desarrollador con Windows Installer / MSI:

  • No puede sobreescribir de manera confiable un archivo de versión inferior con la configuración más reciente.
  • No puede sobrescribir de manera confiable los archivos no versionados (por ejemplo, para IIS).
  • Los archivos faltan misteriosamente después de intentar instalar una actualización de MSI.
  • Los datos se borran durante los escenarios de actualización (principales). Ejemplos incluyen:
    • Su clave de licencia almacenada en el registro .
    • Datos en archivos de configuración como config.xml, settings.ini, etc …
    • Sus credenciales de servicio para el servicio no se ejecutan como LocalSystem.
  • Los datos no se actualizan :
    • Los archivos de configuración no se actualizan de manera confiable durante la instalación con nuevas configuraciones que desea aplicar.
    • Tiene problemas para actualizar la configuración de los archivos de datos almacenados por usuario (o HKCU). Actualiza para el usuario que realiza la instalación, ¿cómo se actualiza para otros usuarios?
  • Verás la patada de auto reparación en forma inesperada para tu paquete.
  • Tu acción personalizada hace que la bomba de configuración salga con misteriosos errores.
  • Y este es uno grande : innecesariamente se usan acciones personalizadas para cosas que ya son totalmente compatibles con el Windows Installer. Este es un gran anti-patrón de implementación y la principal causa de fallas en el despliegue.
    • Instala servicios de Windows a través de acciones personalizadas . Esto se hace mucho mejor en el propio MSI utilizando construcciones integradas.
    • Instala ensamblados de .NET en el GAC a través de una acción personalizada . Esto es totalmente compatible con Windows Installer sin una línea de código (arriesgado).
    • Ejecuta clases personalizadas de instalador de .NET . Estos deben ser utilizados solo para desarrollo y pruebas. Nunca se deben ejecutar como parte del despliegue. Más bien, su MSI debería usar construcciones integradas para implementar y registrar su ensamblaje.
    • Ejecuta configuraciones de requisitos previos e instaladores de tiempo de ejecución a través de una acción personalizada en su propia MSI . Esto debe hacerse de manera completamente diferente. Ver la sección 6.
  • Tiene problemas para implementar archivos de tiempo de ejecución compartidos .
  • La instalación silenciosa de su MSI parece dar como resultado un estado de instalación diferente a la ejecución interactiva de la instalación.

Las siguientes secciones no tienen ningún orden en particular, a partir de ahora.

Las secciones se buscan continuamente para mejorarse. Por favor, agregue comentarios sobre lo que no está claro o útil.

Además pendiente :

  • La desinstalación no funciona para la aplicación MSI – Error 1722
    • Control de servicio : no detener los servicios antes de desinstalar
    • Desinstalación de CA : bash de ejecutar archivos por lotes / scripts que ya no están en el disco durante la desinstalación
    • Acciones personalizadas : acondicionamiento erróneo para que la acción personalizada se ejecute inesperadamente. A menudo en la desinstalación o durante las principales actualizaciones.

1. Problemas de reparación automática

Un problema particularmente molesto se relaciona con construcciones que frecuentemente desencadenan auto reparaciones no deseadas para su aplicación instalada.

  • Debido a la naturaleza multifacética de este problema, he creado una respuesta separada para describir las construcciones de diseño que se deben evitar para evitar que la reparación automática se active sin previo aviso y con intención para su aplicación: ¿Cómo evito que se active la auto reparación de MSI? con mi paquete de WiX / MSI? .

  • A veces, la reparación automática se utiliza como método para llenar HKCU con la configuración de la aplicación o colocar archivos en el perfil de usuario de cada usuario. En general, esto funciona, pero, en mi opinión, no es la mejor práctica para el diseño y la implementación de aplicaciones: consulte más detalles a continuación en la sección 9.

2. Instalación incorrecta de archivos compartidos, de proveedores o de Microsoft en tiempo de ejecución

Aunque esto se explica extensamente en el enlace anterior (problemas de reparación automática), debe señalarse aquí también que uno de los errores más comunes en cualquier configuración es la inclusión de “copias locales” de archivos de tiempo de ejecución compartidos, a veces también registrados a nivel mundial. en el sistema si son archivos COM. Los instaladores de las antiguas aplicaciones VB6 algunas veces hacían esto para los controles comunes que requerían, rompiendo el sistema para otras aplicaciones.

  • Si necesita una versión particular de un archivo compartido para el uso de COM, y no hay manera de que pueda actualizar su aplicación para usar el componente compartido correctamente instalado, entonces puede usar un COM sin registro. Esencialmente, instale copias locales de los binarios que necesita y fuerce su carga sobre los archivos compartidos a través de los archivos de manifiesto proporcionados para los binarios.

  • Consulte el vínculo de problemas de reparación automática en el elemento 1 anterior para obtener más detalles sobre este tema.

3. Manejo incorrecto de (sus) archivos y datos compartidos

Si crea un conjunto de archivos MSI para implementar diferentes productos, es posible que compartan ciertos archivos entre ellos. Si se dirige a la misma ubicación de archivo (ruta absoluta) desde varios archivos MSI, cada uno usando un GUID de componente diferente, entonces cada instalación tratará el archivo como si fuera “suyo”, lo desinstalará felizmente en la desinstalación o lo pondrá de nuevo en su lugar a través de la reparación automática.

  • La solución adecuada para esto es darse cuenta de que para cada ruta absoluta a la que se dirige, debe haber un único GUID de componente. Las rutas absolutas son referencias contadas por un componente GUID y deben compartirse entre todas las configuraciones para que esto funcione correctamente.

  • Para lograr usar el mismo GUID de componente en todas sus configuraciones, debe crear un módulo de fusión para incluirlo en cada configuración o usar construcciones avanzadas en WiX, como “archivos de inclusión”, con GUID codificados para los componentes que contienen.

  • Si el archivo en cuestión es un archivo de datos que nunca debe ser desinstalado o reemplazado una vez actualizado, también debe considerar instalarlo como un “componente permanente” para que no se desinstale durante las principales actualizaciones o ejecute desinstalaciones manualmente.

4. Errores de creación de componentes: no seguir las mejores prácticas

No seguir las mejores prácticas para la creación de componentes. Los componentes MSI son las unidades básicas de instalación para archivos y configuraciones de registro.

  • Existen reglas de mejores prácticas sobre cómo “componentes” sus archivos de aplicaciones. Romper estas reglas puede causar problemas para parches y actualizaciones con síntomas misteriosos, como archivos perdidos y configuraciones después de las actualizaciones, o parches que explotan con errores sin sentido.

  • Para contrarrestar este problema, la simplificación excesiva es que debe usar un archivo por componente a menos que la cantidad de archivos en su configuración sea realmente enorme. Esto evita todo tipo de problemas (lea ese enlace para obtener una explicación más detallada del recuento refinado de componentes).

5. Problemas de actualización relacionados con la sobrescritura o restauración de los datos del usuario

Esto no es menos que extremadamente común . He respondido varias preguntas de stackoverflow sobre este tema, y ​​sigue apareciendo.

  • Lea la sección llamada ” Uso excesivo de archivos por usuario e implementación de registro ” para obtener una descripción de cómo minimizar la dependencia de Windows Installer para la implementación de datos de usuario en general. Si me preguntas, esta es la respuesta real a estos persistentes problemas de “reversión de datos”.

  • Como las actualizaciones son complejas en MSI, muchas se estandarizan en las principales actualizaciones (la forma más simple de actualización). Una actualización importante es esencialmente una desinstalación y una reinstalación del mismo producto (en diferentes versiones).

  • Hay varias formas de configurar una actualización tan importante, pero si desinstala completamente la versión anterior antes de instalar la nueva, puede desinstalar los archivos de datos de usuario que se han modificado desde que se instalaron . MSI no verifica si los archivos de datos han sido modificados desde que se instalaron y los desinstalará felizmente, a menos que haya marcado el componente de alojamiento como ” permanente ” (nunca será desinstalado) o establezca un GUID de componente en blanco para el componente de alojamiento (un característica especial para instalar el archivo y luego ignorarlo por completo).

  • Un caso especial a tener en cuenta es que incluso si comparte correctamente un archivo de este tipo utilizando un módulo de combinación o un archivo de inclusión de WiX (para mantener estable el GUID del componente de instalación), es probable que una actualización importante lo desinstale y reinstale si es solo un producto en la caja que lo ha referenciado en ese momento (el recuento de referencias es 1).
  • Después de que la actualización principal haya finalizado, parece como si los archivos de datos se hubieran sobrescrito o revertido, pero en realidad los archivos de datos modificados simplemente se desinstalaron y luego se reinstalaron en sus “versiones nuevas” (se actualizarán con algunas posibles soluciones para esto pronto) .

  • En mi opinión, solo debe instalar los archivos de datos que se usan de solo lectura después de la instalación. Si los archivos deben escribirse, deben ser generados por la aplicación en mi opinión, y almacenados en el perfil de usuario. Este es un ejemplo de cómo se puede cambiar el diseño de la aplicación para que la implementación sea más confiable. La “solución real” en mi opinión.

  • Si instala el archivo de datos de lectura / escritura con un componente, configúrelo como permanente (o use un GUID en blanco). Las reglas de sobrescritura de archivos garantizarán que el archivo en el disco no se sobrescriba durante la instalación (a menos que haga algo estúpido como configurar REINSTALLMODE como amus para forzar la sobrescritura de todos los archivos; esto nunca debería permitirse. Puede degradar los archivos compartidos instalados por los módulos de combinación también – DLL de estilo antiguo Hell). Si desea borrar el archivo y sobrescribirlo, también es posible usar varios métodos, el mejor de los cuales es probablemente usar un archivo complementario. (más detalles serán agregados más adelante).
  • Wix: el servicio de Windows a veces se desinstala al actualizar

6. Uso erróneo o innecesario de acciones personalizadas

El uso (excesivo) de acciones personalizadas para archivos MSI es un tema enorme y esta sección se volvió demasiado grande y se dividió en una respuesta separada: ¿por qué es una buena idea limitar el uso de acciones personalizadas en mis configuraciones de WiX / MSI? .

Las acciones esencialmente personalizadas a menudo son innecesarias debido al soporte integrado en MSI para lograr el mismo efecto, o la disponibilidad de soluciones ya hechas en marcos libres como WiX o herramientas comerciales como Advanced Installer o Installshield.

Y las acciones personalizadas son, por su propia naturaleza, propensas a errores y la causa principal de fallas y errores de implementación. Por favor, lea el enlace de arriba para más detalles. Miles de personas, decenas de miles de personas, incluso millones de personas han probado estos constructos incorporados. ¿Por qué demonios lo haces por tu cuenta?

Algunos “besserwissing” (consejo que debo seguir): enfóquese en lo que distingue a su producto: qué hay de nuevo en él y elimine todas las otras fonts de errores . Una buena implementación no hará que su producto, pero un mal despliegue puede romperlo.

7. No combinar correctamente los archivos INI

Es posible instalar un archivo INI a través de la tabla Archivo, como lo haría con cualquier otro archivo. Esto no permite la fusión si hay un archivo INI existente en la ubicación de destino.

  • Si importa las entradas INI en las tablas MSI apropiadas, puede actualizar un archivo INI existente usando “fusión” con valores existentes, y no solo hacer que un archivo sobrescriba “borrar” las entradas existentes, o no actualizar el archivo en absoluto.

  • La “fusión de INI” es “auto-magia” que permite un adecuado soporte de reversión y actualizaciones “puntuales” de los valores en cualquier archivo INI existente. Si el instalador se cancela, el archivo INI se revierte adecuadamente a su estado inicial.

  • Esta es una excelente característica que realmente funciona muy bien para casi cualquier archivo INI que haya visto. Sin embargo, de hecho, he visto algunos casos en que los archivos INI tienen un formato no estándar. A veces tienen grandes secciones de comentarios que desea instalar (herramientas de desarrollador) o formatos extraños que no pueden ser compatibles con la fusión de MSI (archivos triples delimitados por comas y cosas por el estilo). En estos casos, debe instalarlo como un archivo en lugar de como una “transacción de cambio” para preservar el archivo INI con formato único.

  • Si está desarrollando y utilizando un archivo INI no estándar, considere darle al archivo una extensión diferente a * .INI para indicar su singularidad y la necesidad de un manejo especial. En realidad, ya no es un archivo INI (formato de clave-valor). Lo contrario también es cierto: tiene una extensión única, y puede cambiarla a INI para manejarla como un archivo INI adecuado si el contenido del archivo es pares clave-valor.

8. Usar erróneamente el autorregistro para archivos COM

O instale su registro a través de la tabla de Registro. Use las tablas de publicidad COM apropiadas. Hay muchas razones, como se explica aquí: Autoregistro considerado dañino .

  • He visto casos en los que el autorregistro realiza otras acciones además del registro COM real en el sistema en cuestión. En general, este es un diseño horrible del desarrollador en cuestión, pero conozco casos en los que las personas han elegido usar el autoregistro en lugar de volver a implementar lo que se hace durante el autoregistro como una acción personalizada adecuada.

  • Para permitir una opinión personal: cuando veo que la configuración de red se ve afectada por el registro automático, inmediatamente deseo que el software se rechace para usarlo por completo. Eso es lo serio que es hacer algo tan “hacky” en una operación estandarizada como el autoregistro. La pregunta más acertada es: “¿qué más están haciendo dado ese registro COM dudoso”. Simplemente no es un creador de confianza para confiar en cosas no estándar, hacky.

9. Uso excesivo de archivos por usuario e implementación de registro

ACTUALIZAR : nueva respuesta relacionada con este tema: Crear carpeta y archivo en Perfil de usuario actual, desde Perfil de administrador .

Esta sección se volvió demasiado grande y se dividió en una respuesta separada: ¿por qué es una buena idea limitar el despliegue de archivos al perfil de usuario o HKCU cuando se usa MSI?

La implementación de archivos o configuraciones esencialmente de perfil de usuario en HKCU es tolerable, pero puede que no sea el mejor diseño, y puede ser engorroso garantizar que todas las configuraciones y archivos lo incluyan en cada registro de usuarios y perfil en la caja. Los problemas de implementación que resultan y algunas soluciones propuestas se discuten en la respuesta vinculada anteriormente.

Esencialmente, la implementación del usuario puede ser soportada usando la reparación automática de MSI, la instalación activa de Microsoft, o mediante cambios de diseño lógico a la aplicación o solución en cuestión (la opción preferida – vea la respuesta vinculada para más detalles). En general, la implementación no debe interferir con la configuración y los datos del usuario, ya que en realidad se trata de datos del usuario y la aplicación no debe implementarlos, sino generarlos en tiempo de ejecución.

10. La instalación silenciosa no se completa o está incompleta

Una característica incorporada de Windows Installer es que cualquier archivo MSI se puede instalar en modo silencioso. Esta es una característica central de la tecnología diseñada para ayudar a la implementación corporativa, que generalmente siempre se ejecuta en modo silencioso. Asegurarse de que su MSI sea capaz de completar y trabajar con éxito después de una instalación silenciosa, no es menos que excepcionalmente importante . En mi experiencia, las acciones personalizadas a menudo pueden causar problemas para la instalación silenciosa.

  • Nunca realice cambios en la computadora desde InstallUISequence (desde sus cuadros de diálogo de configuración). Este problema fue descrito arriba. Las acciones personalizadas que se utilizan en la GUI interactiva son de modo inmediato (sin elevación para los usuarios normales) y solo deberían recostackr y validar la entrada del usuario (solo lectura). Todos los cambios no estándar realizados en la computadora deben realizarse entre InstallInitialize e InstallFinalize en InstallExecuteSequence: las operaciones transaccionadas y elevadas donde solo se pueden ejecutar el modo diferido y las acciones personalizadas elevadas.

    • Todos los cambios realizados en InstallUISequence también se omitirán por completo cuando se ejecute en modo silencioso, y la instalación probablemente estará incompleta. La instalación silenciosa es extremadamente importante para la implementación corporativa: en general, la GUI siempre se ignora y los cambios se aplican mediante el uso de transformaciones y / o propiedades de configuración desde la línea de comandos.

    • Aquí hay una larga discusión sobre cómo las instalaciones silenciosas e interactivas y las desinstalaciones pueden arrojar resultados diferentes (y cómo es un defecto serio de diseño de MSI): La desinstalación desde el Panel de control es diferente de la eliminación de .msi

  • Nunca muestre cuadros de diálogo desde sus acciones personalizadas en InstallExecuteSequence . Hacerlo puede causar que la instalación silenciosa falle por completo, ya que estos diálogos no obedecerán automáticamente la configuración de UILevel de la instalación en ejecución. Cuando la configuración se ejecuta en modo silencioso a través de los sistemas de despliegue, un diálogo modal puede aparecer y bloquear la finalización de la configuración, y no habrá ningún usuario para cerrar el diálogo, por supuesto. Puede usar la propiedad UILevel para determinar si la configuración se ejecuta en silencio y luego suprimir la visualización de su diálogo, pero mostrar un diálogo como este es simplemente un diseño incorrecto.

11. Intenta “forzar sobreescribir” archivos con su instalador MSI

MSI presenta algunas ” reglas de control de versiones de archivos ” bastante complejas diseñadas para minimizar el impacto de ” DLL Hell “. Normalmente provocan que los archivos no se sobrescriban según lo previsto, un problema clásico de MSI. Como resultado, las personas sienten que no pueden encontrar una manera confiable de forzar siempre la sobrescritura de archivos en el disco durante la instalación.

  • Hay formas de forzar la sobreescritura de archivos, pero no de la forma en que la mayoría de las personas lo consideran lógico. Francamente, el diseño de reemplazo de archivos a menudo es mal visto incluso cuando se entiende.

  • La sobrescritura de archivos funciona de manera bastante diferente para los archivos versionados y los archivos de datos (texto, imágenes, cualquier cosa sin una propiedad de versión). En esencia, los archivos versionados superiores sobrescriben los archivos de versiones más bajas cuando se versionan los archivos. Los archivos de datos no se reemplazan si las fechas de creación y modificación son diferentes para el archivo en cuestión. Luego se ha modificado desde que se instaló.

  • El comportamiento de sobrescritura de archivos puede modificarse ligeramente mediante configuraciones personalizadas para la propiedad REINSTALLMODE establecida en el nivel de línea de comando de msiexec.exe (sobrescribir versiones anteriores, sobrescribir versiones iguales, sobrescribir cualquier versión, etc.). Establecer la propiedad REINSTALLMODE cambia la lógica de reemplazo de archivos para todos los archivos en toda la configuración, incluidos los archivos implementados con módulos de fusión que pueden orientar los archivos en ubicaciones compartidas. Por lo tanto, podría degradar los archivos y componentes compartidos, exactamente de qué se trataba “DLL Hell”.

  • Sin embargo, es crucial comprender las “reglas de sobrescritura de archivos” y cómo pueden verse afectadas por la configuración, pero es una configuración que se aplica a todos los archivos de la instalación completa. También hay algunos “hacks” para sobrescribir solo archivos específicos.

  • Consulte este artículo sobre cómo puede forzar la sobreescritura de un archivo que no se actualizará .

  • Esta sección aún no está terminada.

12. Instala servicios que se ejecutan con credenciales de usuario

En mi opinión, esto no es una buena práctica y, por lo general, las personas eliminan también las credenciales durante los principales escenarios de actualización, y en algunos casos también los archivos de configuración que usa el servicio.

  • Para mí, este es un excelente ejemplo de cómo se necesitan los cambios en el diseño de las aplicaciones para que la implementación sea confiable y sensata.

  • En mi experiencia, la gente insiste en usar estas soluciones y termina con una gran cantidad de piratería de acción personalizada para que funcione.

  • Ahórrese muchos problemas y diseñe su servicio para que se ejecute como LocalSystem ( o tal vez mejor, otra cuenta que esté destinada al uso del servicio ), tenga una lectura rápida de este contenido vinculado y hable con su equipo de desarrollo sobre las opciones. Aquí hay otra publicación que valdría la pena descremada: ¿es seguro ejecutar un grupo bajo NT AUTHORITY \ NETWORK SERVICE? ).

  • Consulte la siguiente sección sobre privilegios de NT para ver un problema común al usar credenciales de usuario para ejecutar un servicio.

  • ACTUALIZACIÓN : también se debe mencionar el nuevo concepto de cuentas de servicios gestionados . Paso a paso (también vea la sección en esta respuesta en las cuentas de servicios administrados y grupales ).

13. Su aplicación requiere amplios privilegios NT personalizados

Los privilegios de NT son diferentes del control de acceso discrecional (el control de acceso del sistema de archivos y objetos de registro) e incluyen cosas como SeServiceLogonRight “inicio de sesión como servicio” (que debe configurarse para cualquier cuenta de usuario que intente ejecutar un servicio; una configuración muy común problema para las configuraciones que intentan ejecutar servicios con credenciales de usuario).

En algunos casos, se requieren una gran cantidad de dichos privilegios para ejecutar una aplicación o, más probablemente, un servicio. Un “olor de despliegue” muy fuerte o, en realidad, un “olor a solución”: un antipatrón si alguna vez hubo uno.

Casi todos estos privilegios son peligrosos de desperdiciar .

  • Supongo que SeSystemtimePrivilege – configurar el tiempo del sistema no es demasiado crítico – al menos a su valor nominal, pero realmente no veo ningún privilegio totalmente inofensivo, y además del inicio de sesión del servicio mencionado anteriormente, pocos deberían ser necesarios.

  • En mi experiencia, los privilegios solicitados tienden a girar en torno a ” Derechos de usuario de inicio de sesión “. SeNetworkLogonRight (acceso a la computadora desde la red), SeInteractiveLogonRight (inicie sesión localmente), SeBatchLogonRight (inicie sesión como un trabajo por lotes) y el más grande: SeServiceLogonRight (inicie sesión como un servicio).

  • Ciertos privilegios de NT como SeAssignPrimaryTokenPrivilege , SeBackupPrivilege , SeDebugPrivilege , SeIncreaseQuotaPrivilege , SeTchPrivilege (actúan como parte del sistema operativo) y muchos otros nunca deben ser aplicados por ningún paquete de código .

  • La cuenta de LocalSystem destinada a ejecutar servicios tiene la mayoría de los privilegios (incluidos los peligrosos) y debe utilizarse para ejecutar su solución en lugar de crear una cuenta de usuario separada y asignarle estos privilegios. En serio .

  • Aquí hay una buena ” lista agrupada de privilegios de NT ” que proporciona un poco más de contexto para comprender para qué sirve cada privilegio y cómo se relacionan.

14. Aplica mucho permiso personalizado de disco y registro

Este es un “olor de despliegue” definitivo o despliegue “antipatrón”. En casi todos los casos, esto se puede evitar rediseñando la aplicación en cuestión.

  • La aplicación de permisos personalizados se ha realizado tradicionalmente utilizando varias herramientas de línea de comandos. También hay características incorporadas en MSI para hacer esto, pero carecían de flexibilidad.

  • Con la llegada de WiX, la aplicación de permisos ahora es relativamente confiable porque es una solución probada adecuadamente por desarrolladores que entienden MSI. Las herramientas comerciales también admiten permisos personalizados, por supuesto.

  • En mi opinión, los permisos personalizados siguen siendo una señal de que algo está mal con el software que está instalando, pero también he aplicado muchos permisos personalizados.

  • A menudo he visto problemas repetitivos de reparación automática causados ​​por permisos defectuosos aplicados al disco o al registro: ¿Cómo evito activar la autorreparación de MSI con mi paquete de WiX / MSI? (sección 5).

  • También he visto varios casos donde los permisos erróneos aplicados crean una situación en la que la desinstalación se vuelve imposible sin algunos ajustes serios a los permisos de ACL fallidos. Trabajo muy retorcido, y muy fácil de empeorar al tratar de implementar y corregir automáticamente.

  • Otro problema obvio es el riesgo de seguridad que introduce al abrir el acceso de escritura a las ubicaciones por máquina en la máquina.

15. Su clave de licencia en el registro se restablece al actualizar

Un diseño muy común es escribir una clave de licencia para el registro utilizando un componente MSI. Puede ser HKCU o más a menudo HKLM, para convertirlo en una licencia compartida para todos los usuarios en la misma máquina.

Si usa una propiedad pública de MSI para configurar esta clave de licencia, debe leer este valor nuevamente en una nueva instalación para asegurarse de que no sobrescribe los datos existentes allí con una cadena vacía. Las propiedades públicas de MSI (sorprendentemente) no se conservan y la configuración de la actualización las lee automáticamente en los principales escenarios de actualización. Olvidar hacer esto es una causa muy común de personas que ven su clave de licencia eliminada durante una actualización mayor.

Raramente, si alguna vez, recomiendo leer / escribir acciones personalizadas. Son propensos a errores y pueden ser complejos para hacer las cosas bien, y la mayoría de las personas nunca implementa una reversión adecuada (si la configuración se bloquea y necesita deshacerse). Sin embargo, también tiene más poder para verificar el “estado actual” del sistema con una acción personalizada, y puede condicionar su acción personalizada para que siempre se ejecute, incluso durante la secuencia de parchado, y puede hacer que haga cosas diferentes durante secuencias diferentes si necesitas. La mayoría de las veces, puede ser realmente un problema que las acciones personalizadas se ejecuten cuando no están previstas, por ejemplo, durante la instalación de un parche. Pocas personas recuerdan condicionar su acción personalizada con NOT PATCH (para evitar que se ejecute durante el parcheo).

A pesar de todo esto, es posible que use una acción personalizada para escribir una clave de licencia para HKLM durante la instalación si se me indica que escriba la licencia durante la instalación. Sin embargo, y esto es importante, preferiría eliminar todo el problema de licencia de la configuración por completo , por muchas razones que se describen aquí: Instalador con registro en línea para la aplicación de Windows (lectura recomendada – hay muchas razones para mantener la licencia fuera de su configuración).

16. GUIDES codificados no deseados indeseables

Algunos GUID pueden estar codificados en su archivo fuente de WiX (u otra herramienta de creación de MSI). Por ejemplo, GUID de componentes: deben permanecer estables para cada componente, a menos que cambie la ubicación de instalación. La justificación para esto se intenta explicar aquí: ¿ Cambiar mi GUID de componente en wix?

Sin embargo, no codifique el código del paquete . El código de paquete de MSI siempre debe generarse automáticamente para cada comstackción. Simplemente se supone que es único. Con más detalle; la idea de un paquete GUID es que debe ser único para cada archivo MSI comstackdo. Está simplemente allí para identificar de manera única un archivo. Dos archivos MSI diferentes con el mismo paquete GUID serán tratados por Windows Installer como el mismo archivo por definición. Todo tipo de problemas con los archivos X resultan. En consecuencia, un GUID de paquete siempre debe generarse automáticamente ya que se supone que es único.

Muchos también generan automáticamente el Código del producto , ya que solo utilizan actualizaciones importantes para actualizar sus aplicaciones. Para este caso de uso, los Códigos de producto generados automáticamente funcionan bien. Sin embargo, si necesita admitir actualizaciones menores de Windows Installer también, debe codificar su Código de producto y actualizarlo cuando corresponda. El Código de actualización generalmente debe estar codificado y gestionado manualmente. Vea esta respuesta .

17. Inclusión Errónea de Datos Sensibles

Ahora hay una Q / A separada sobre el tema de evitar que los datos confidenciales terminen en su instalador final: ¿Cómo evito distribuir información confidencial en mi MSI por accidente?

Esencialmente, el consejo es darles a tus archivos una vez más para los pecados del paquete de desarrollo codificados . ¿Cómo verificar ? No me gusta, abro el MSI con Orca , y hojeo las tablas . Las tablas más vulnerables son probablemente: Registry , Property , IniFile , tal vez Directory , y si usa la GUI de MSI: all tables relating to GUI . Cualquier secuencia de comandos (tabla CustomAction o tabla Binary ; esta última requiere que transmita secuencias de comandos) o las verifique en sus ubicaciones de origen).