La desinstalación del Panel de control es diferente de Eliminar de .msi

¿Hay alguna diferencia entre desinstalar una aplicación con .msi basado en WiX desde el Panel de control y desde el propio .msi?

Si hay lo que es?

Lo estoy preguntando por la siguiente razón:

La diferencia es la siguiente: mi .msi almacena algunos archivos en% PROGRAMDATA%. Si desinstalo desde el Panel de control, los archivos se desinstalan (parece que el .msi realiza un seguimiento de ellos (están definidos como componentes)), pero cuando abro mi .msi e bash desinstalar (tengo un diálogo de mantenimiento) aquellos los archivos no se eliminan

Otra diferencia es: también tengo una acción personalizada para detener mi aplicación si se está ejecutando, que se llama After = “AppSearch” en InstallUISequence y Before = “CostFinalize” en InstallExecuteSequence pero al eliminar de .msi no es siendo llamado. Solo aparece un cuadro de diálogo que dice que hay archivos para eliminar pero que están siendo utilizados, pero algunos procesos y cuando digo que los detenga no funciona.

La siguiente “discusión” se salió un poco de las manos. Pero lo dejaré aquí como una explicación para las personas que investigan las diferencias experimentadas entre el modo silencioso y las instalaciones en modo interactivo.

, la respuesta corta es que , de hecho, puede ver un comportamiento diferente de instalación o desinstalación según cómo invoque la (des) instalación .

Esto tiene que ver principalmente con cómo un MSI puede ejecutarse con diferentes niveles de interfaz de usuario , y esto hace que toda la secuencia de la interfaz de usuario ( InstallUISequence ) en el MSI se ejecute o se omita por completo (instalación silenciosa). Una vez omitido, todas las acciones personalizadas definidas solo en InstallUISequence no se ejecutarán en absoluto. Si el MSI está bien diseñado , esto no es un problema ya que las acciones personalizadas de la interfaz de usuario se ejecutan en modo inmediato y nunca deben hacer cambios en el sistema; solo deben consultar los datos y configuraciones del usuario, estado del sistema o ayudar al usuario a ingresar los datos correctos para la instalación. Si el MSI no está bien diseñado y se realizan cambios en el sistema en la interfaz de usuario, la instalación estará incompleta cuando se ejecute en modo silencioso. Este es un grave error de diseño de MSI que se vuelve aún más serio cuando te das cuenta de que todas las grandes corporaciones implementan software silenciosamente. He visto esos errores muchas veces al hacer el reempaquetado de aplicaciones corporativas. No es un voto de confianza para el software, no importa cuán bueno sea. Problemas raros e impredecibles están destinados a la superficie.

En consecuencia, InstallExecuteSequence (que es el único que se ejecuta cuando la instalación se instala de forma silenciosa) debe tener todas las acciones personalizadas requeridas que hagan que los cambios en el sistema se inserten allí para que una MSI se diseñe correctamente. Como ya se mencionó, las acciones personalizadas que existen solo en la secuencia de la interfaz de usuario deben tratar de obtener valores y configuraciones del usuario, mientras que estos valores deben establecerse y definirse por línea de comando o definirse en transformaciones para una instalación silenciosa.

Ciertas combinaciones extrañas y erróneas de condiciones de acción personalizada también pueden causar diferencias entre instalaciones interactivas y silenciosas en circunstancias especiales. Y finalmente poner acciones personalizadas después de InstallFinalize en InstallExecuteSequence puede causar que las acciones fallen cuando se ejecutan silenciosamente. Ciertamente hay otros problemas potenciales también.

En resumen, si observa una diferencia en el comportamiento de la instalación en función del nivel de la interfaz de usuario, su MSI contiene una falla de diseño grave . Siempre debe asegurarse de que su MSI se pueda ejecutar en silencio con el resultado equivalente de forma interactiva. Y como ya se ha dicho, las grandes corporaciones nunca ejecutan instalaciones de forma interactiva, ya que expulsan el software a través de sistemas de administración de software como SCCM.

  • Hay 4 niveles de MSI UI que van desde completamente silenciosos hasta completamente interactivos :

    • INSTALLUILEVEL_NONE = 2, (totalmente silencioso)
    • INSTALLUILEVEL_BASIC = 3, (barras de progreso y manejo simple de errores)
    • INSTALLUILEVEL_REDUCED = 4, (interfaz de usuario creada, sin asistentes)
    • INSTALLUILEVEL_FULL = 5 (interfaz de usuario completa)
  • El punto importante es que para UILevel 2 y 3 se omite InstallUISequence .
  • Existe una propiedad MSI UILevel que contiene los valores de nivel GUI 2, 3, 4 o 5. Compruebe esta propiedad si su acción personalizada debe tener en cuenta el tipo de interfaz de usuario. Esto es obviamente más importante para las instalaciones totalmente silenciosas que nunca deberían mostrar ningún cuadro de diálogo.

  • Cuando haces clic derecho en un MSI y seleccionas desinstalar, generalmente estás ejecutando UILevel 3 (UI básica con barra de progreso). Esto significa que la secuencia de InstallUIS se omite.

  • Cuando desinstalas desde Agregar / Quitar progtwigs, el UILevel normal también es 3 – Interfaz de usuario básica. Esto significa que la instancia de InstallUIS también se omite.
  • Si hace doble clic en MSI y ejecuta la desinstalación, su nivel de GUI es 5: GUI completa. Lo mismo ocurre si selecciona “Cambiar” en los progtwigs para agregar / eliminar.

En resumen, es posible que aparezcan errores solo en uno de los modos (silencioso / no silencioso) porque la secuencia de interfaz de usuario del MSI se omite junto con todas sus acciones personalizadas para ciertos niveles de interfaz de usuario. En otras palabras, un producto podría funcionar cuando se instala de forma interactiva y fallar cuando se instala silenciosamente (o viceversa), si el MSI está mal diseñado.

También es posible condicionar erróneamente acciones personalizadas en la secuencia de instalación principal de MSI en función de esta característica UILevel, de modo que los resultados difieren según el modo de instalación. He visto personas generar diálogos del código en acciones personalizadas ubicadas en la secuencia de instalación principal (donde no se permite la interactividad) y luego usar las comprobaciones UILevel para suprimir el diálogo en modo de instalación silenciosa (o lo olvidan también, activando un diálogo modal oculto) que detiene la instalación muerta cuando se ejecuta en modo silencioso). Estas extrañas construcciones de diseño provocan un comportamiento de instalación inesperado en función de cómo se desencadena y ejecuta la instalación.

Aunque esto no es una respuesta a lo que usted pidió, una conclusión final de todo esto es que si su software está destinado a grandes corporaciones, no debe perder sus esfuerzos de diseño en una interfaz gráfica de usuario avanzada para su configuración, ya que es probable que nunca ser utilizado para escenarios de implementación a gran escala. En su lugar, debe parametrizar su instalador con propiedades públicas que se pueden establecer en la línea de comando o mediante una transformación para que su instalador pueda controlarse fácilmente sin ejecutarlo de manera interactiva. Ver esta publicación: Cómo hacer un mejor uso de los archivos MSI .

Dado que he ido más allá de su pregunta, también debo señalar que algunos instaladores avanzados destinados a instalaciones de servidores pueden (con moderación) beneficiarse de una buena GUI para ayudar a las personas a instalar y probar rápidamente su software de servidor. Estos instaladores tienden a entrometerse con características muy avanzadas como IIS, MS SQL, AD, etc. … y se podría desear cierta interactividad para los administradores de sistemas expertos. Pero como dice el refrán, “la mayoría de las cosas pueden ser predeterminadas” y, por lo general, es más fácil que las personas se instalen y prueben ya sea que tengan conocimientos o no. Actualmente, muchas grandes empresas ejecutan granjas grandes de servidores virtuales (un servidor virtual por caso de uso), por lo que incluso las instalaciones del servidor tienden a automatizarse para el despliegue a gran escala y luego se aprecia un buen instalador parametrizado con propiedades públicas para establecer. Las empresas más pequeñas también pueden tener servidores virtuales (lo que hace que las pruebas sean fáciles), pero es probable que instalen su configuración aceptando interactivamente los valores predeterminados, al menos esa es mi impresión.

No hay diferencia práctica entre hacer clic derecho en un MSI para desinstalarlo y usar el Panel de control para desinstalarlo. Ambos dan como resultado una desinstalación mínima de UI (no totalmente silenciosa, muestra barra de progreso), y pedirá la elevación si es necesario.

Si tiene un cuadro de diálogo de modo de mantenimiento en su configuración, entonces puede tener una ruta ligeramente diferente: puede mostrar un cuadro de diálogo que ofrece cambiar características, reparar o desinstalar. Eso podría resultar en una diferencia en alguna parte.

Si hay algún código en alguna parte que altera algo, ¿quién sabe? Una desinstalación de un diálogo puede optar por suprimir el botón Cancelar, como un ejemplo al azar.