¿Por qué es una buena idea limitar el uso de acciones personalizadas en mis configuraciones de WiX / MSI?

¿Por qué es una buena idea limitar el uso de acciones personalizadas en mis configuraciones de WiX / MSI?


El despliegue es una parte crucial de la mayoría del desarrollo. 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 tipo Q / A dividida de una respuesta que se volvió demasiado larga: ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI? .

Versión corta “Folksy” :

En general : una configuración moderna debe ser “declarada”, no codificada. “pensar consultas SQL, no secuencias de comandos”. Aplique la lógica bien probada que acaba de invocar para hacer el trabajo. Más sobre eso más tarde.

  • Evite acciones personalizadas si puede .
    • ¡Te atornillarán la cabeza (y asesinarán a tu figura femenina)!
    • En serio: son la causa principal de falla en el despliegue .
    • Presentan una ” complejidad conspiratoria ” por la cual las cosas a menudo se rompen inesperadamente y sin previo aviso después de haber desplegado su configuración por un tiempo y está “en la naturaleza”.
    • La implementación es un proceso : tendrás que lidiar con ” pecados pasados ” en cada nuevo lanzamiento. Puede convertirse en una verdadera pesadilla limpiar cosas después de despliegues interrumpidos. Cada iteración agrega fonts de error nuevas y potenciales (mi solución para mi corrección fallida, fallida, etc.).
    • Los requisitos de tiempo de ejecución para el código administrado y las acciones personalizadas de scripting son muy propensos a errores (.NET, en particular, en mi opinión). Una configuración, en todo caso, debería incluir ” dependencias mínimas “, ya que se usa para instalar dependencias directamente y debe ejecutarse en ” cualquier máquina ” en ” cualquier estado ” en ” cualquier idioma “.
    • Además de utilizar construcciones integradas de MSI o funciones personalizadas de WiX, a menudo se pueden evitar acciones personalizadas mediante pequeños cambios en el diseño de la aplicación, de modo que ya no se necesitan acciones personalizadas complejas (ejemplos a continuación).
  • Dedique su tiempo a buscar y revisar las características y extensiones integradas de MSI de WiX , Installshield , Advanced Installer (y otras herramientas de proveedores ).
    • Estas extensiones están hechas por los mejores expertos en implementación disponibles y, en la mayoría de los casos, han sido probadas por miles de personas (millones y miles de millones en el caso de las funciones incorporadas de MSI).
    • ¿Cómo puede concordar esto con su propio código propietario? Si la solución existente es lo suficientemente buena, lo que normalmente es, entonces su propio código se agrega por completo al riesgo sin ganancia alguna . Las soluciones ya preparadas incluso admiten la reversión , una característica notoriamente descuidada y difícil de implementar, que en realidad requiere el diseño.
    • En otras palabras: cuando utiliza las soluciones existentes, toma prestadas no solo la implementación, sino también el control de calidad , UAT y las pruebas de las extensiones cuando las usa. Esto puede ahorrar semanas de trabajo y contribuir en gran medida a la estabilidad del despliegue .
    • Todo lo que se necesita es dedicar un tiempo a buscar y leer lo que ya está disponible, en lugar de comenzar con su propio código. Diablos, incluso su propio gerente podría involucrarse buscando … En un mundo de ensueño.
    • ¡Una configuración generalmente no debe codificarse, debe declararse! (piense en SQL). De esto se trata Windows Installer: usted declara qué se debe instalar y el motor de instalación se ocupa de la secuencia. Resultado de beneficios: cuando se hace bien.
  • Eso es todo realmente. ¡Sigue leyendo si te atreves! Aquí hay dragones en medio de graves vociferaciones. Y, lo que es más importante: una experiencia de la vida real al lidiar tanto con el desarrollo de la configuración como con la implementación a gran escala de dichas configuraciones en entornos corporativos. Los problemas comunes se vuelven más claros: son más identificables. Y puede quemarse con problemas por los que realmente tiene que responder, que siente que nunca podría haber previsto (hacer embalajes y embalajes corporativos para ver cuánto puede estar mal con un solo paquete; puede llevar días superarlos). en forma a veces).
    • Recuerde, y esto no es tan malo como parece: la implementación generalmente es un esfuerzo de tecnología de bajo nivel, pero una falla de alto perfil. Los errores realmente muestran . Y alguien responderá y el soporte realmente lo sentirá.
    • La depuración durante el desarrollo es difícil, pero para el despliegue a veces es casi imposible ya que generalmente no tiene acceso a los sistemas problemáticos, y cada sistema problemático estará en un estado totalmente diferente.
    • Honestamente: no lograr que el software se implemente correctamente para los usuarios finales puede ser el error más costoso en el desarrollo de software, nadie puede ver la grandeza de su solución y afecta las ventas, el soporte, el marketing y el desarrollo de soluciones adicionales .
    • La implementación deficiente definitivamente puede hundir un producto . Lamentablemente, una buena implementación no es suficiente para guardar un producto .

Versión cargada de Ranting 🙂

Como se indicó anteriormente, esta sección se dividió a partir de una respuesta existente con un scope más amplio : ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI? (una respuesta destinada a ayudar a los desarrolladores a tomar mejores decisiones de implementación).

6. Uso erróneo o innecesario de acciones personalizadas .

El uso de acciones personalizadas puede generar una plétora de problemas de implementación, la mayoría de ellos muy graves. Si su configuración no se completa o falla, es una buena apuesta que una acción personalizada errónea es la culpa.

En consecuencia, la solución obvia es limitar el uso de acciones personalizadas siempre que sea posible . Las acciones personalizadas son (a menudo) ” caja negra ” (código oculto), mientras que la mayoría de MSI tiene mucha transparencia. El formato MSI se puede ver fácilmente ( archivo de almacenamiento estructurado por COM ) y todo lo que hace un archivo MSI se puede deducir esencialmente de su archivo de base de datos MSI, con la excepción de las acciones personalizadas comstackdas (las acciones personalizadas de script siguen siendo un recuadro blanco; ver lo que está pasando, a menos que estén ofuscados).

En esta era del malware , estas acciones personalizadas de caja negra, que se ejecutan con derechos elevados, pueden ser mal vistas en más de un sentido. No son solo problemas de estabilidad y confiabilidad, sino un verdadero problema de seguridad.

6.1 El uso excesivo de acciones personalizadas

  • Disculpe las “pequeñeces” que se enumeran a continuación. Mucho de esto puede ser banal, pero tal vez use los argumentos enumerados para justificar que evite las acciones personalizadas y trabaje en mejores soluciones, lo que generalmente implica una secuencia de inicio de aplicaciones más inteligente y la autoconfiguración de la aplicación. Confíe en nosotros, la encoding de la aplicación será más interesante que tratar con el complejo acondicionamiento, secuenciación y suplantación del Instalador de Windows para acciones personalizadas.
  • Lo siguiente se ha actualizado tantas veces que las secciones están un poco fuera de secuencia o son repetitivas aquí y allá. Será limpiado cuando el tiempo lo permita.
  • Los desarrolladores son buenos en la encoding, por lo que con todo el respeto, tienden a abusar de las acciones personalizadas para hacer cosas que se hacen mejor usando las funciones integradas de MSI o las soluciones de extensión de MSI preparadas , como las disponibles en WiX para cosas avanzadas como XML actualizaciones de archivos , IIS , COM + , reglas de firewall , instalación de controladores , permisos personalizados para entradas de disco y registro, modificación de privilegios NT , etc. … Esta compatibilidad también se encuentra en herramientas comerciales como Installshield y Advanced Installer.
  • También es posible hacer mucho de lo que se hace en la acción personalizada como parte de la secuencia de inicio de una aplicación . El mejor ejemplo es inicializar los datos del usuario y copiar el archivo de configuración a cada perfil de usuario . Aquí hay un pequeño resumen de este problema: Crear carpeta y archivo en Perfil de usuario actual, desde Perfil de administrador .
  • Es obvio, pero con mucha frecuencia las acciones personalizadas se utilizan por ignorancia de lo que ya está disponible “de fábrica” ​​mediante soluciones ya preparadas. Esto nos sucede a todos nosotros todo el tiempo, ¿no es así? ¿Siempre hay alguna forma más inteligente de hacer cosas que te hubieran ahorrado mucha pena? En general, de todos modos, aunque a veces estás abriendo nuevos caminos. No inicie un camino nuevo en su configuración, a menos que sea absolutamente necesario. Guárdelo para su aplicación.
  • Quiero enfatizar que estas soluciones integradas de Windows Installer y extensiones de WiX y herramientas comerciales han sido escritas por los mejores especialistas en implementación disponibles . Y, además, y lo que es más importante, han sido utilizados y probados por miles, millones, incluso miles de millones de personas para las funciones incorporadas de MSI. ¿De verdad crees que puedes hacer algo mejor? Moraleja de la historia: elige tus batallas y utiliza tus excelentes habilidades de encoding para resolver nuevos problemas, y deja que la implementación sea lo más estúpida posible . Usa lo que ya funciona, y no reinventes la rueda. Hay demasiadas incógnitas en la implementación, demasiadas variables que no se pueden controlar: se trata de ” cualquier máquina ” en ” cualquier estado ” y en ” cualquier idioma “. Consulte la sección Complejidad de la implementación aquí si desea ejemplos, un poco más abajo en la página, solo un breve resumen de todas las formas en que sus sistemas de destino pueden diferir en sus estados cuando su paquete llega. Cada variable es una nueva trampa para osos para código personalizado, desde la versión del sistema operativo hasta el estado de la aplicación y la situación del malware . La lista sigue y sigue . Como dice la conclusión en el contenido vinculado: “La implementación es un concepto simple, con una combinación complicada de variables que pueden causar los errores más misteriosos, incluido el favorito del desarrollador: el error intermitente . Como todos sabemos, la gravedad de esos errores no puede ser exagerado, ya que a menudo son imposibles de depurar correctamente.
  • Ciertas cosas avanzadas deben hacerse en su configuración, ya que requieren derechos elevados y su aplicación no debe solicitar esto mientras se ejecuta. Esto es lo que una configuración es para una configuración avanzada y elevada del sistema, así que adopte esta complejidad, ¡pero use soluciones ya preparadas! No mueva su propia secuencia de comandos y soluciones, use cosas incorporadas y bien probadas. ¿Su script se ejecutará correctamente en Corea? ¿Su acción personalizada será bloqueada por una importante solución de calibre antimalware con la que nunca tuvo tiempo de probar su secuencia de comandos? ¿Tiene tiempo para escribir su propio cheque para ver si se ha instalado un cierto requisito previo de tiempo de ejecución en la computadora, que funciona en todas las configuraciones regionales y en todas las versiones del sistema operativo? El potencial de errores aquí es asombroso , y a veces imposible de probar correctamente . ¿Tiene máquinas de prueba en árabe, chino, coreano o japonés? Quizás tú sí. ¿Pero tienes un servidor de terminal para probar? ¿Qué tal un servidor de terminal coreano? ¿Probaste tu configuración con la publicidad de MSI? Para que las funciones avanzadas de administración de sistemas funcionen, debe hacer que su configuración sea lo más estúpida y estándar posible . Pasaré varios días buscando soluciones prefabricadas antes de escribir algo por tu cuenta, diría yo . Recuerda, con las soluciones ya preparadas no solo estás pidiendo prestado su código, sino también el control de calidad, pruebas y UAT de su creador, que casi no puedes esperar repetir.
  • Las pruebas del mundo real son el único criterio importante: no hay sustituto. ¡No te enfrentes a este mundo de dolor! Un ligero cambio en Windows implementado a través de una actualización de Windows y su acción personalizada se rompe de muchas maneras. Elija una mejor batalla para hacer uso de sus habilidades. Si lucha contra el diseño, el instalador de Windows se defiende.
  • Y están sucediendo muchas cosas con el despliegue que lo hacen complejo, y no tonto como nosotros queremos (simplemente copie algunos archivos malditos), su lucha es para hacerlo lo más simple posible, pero no más simple . Aquí hay una lista de tareas de implementación que muestra por qué es difícil hacer que su paquete sea lo suficientemente “tonto”: ¿Cuál es el beneficio y el verdadero propósito de la instalación del progtwig? Utilice solo construcciones ya hechas siempre que pueda, es la primera victoria fácil. Todo lo que necesitas hacer es leer y buscar un poco.
  • Finalmente, agregaré que se supone que todas las acciones personalizadas admiten la reversión para devolver el sistema al estado original si falla la instalación. En el mundo real, esto casi nunca se hace en una acción personalizada ad-hoc (en mi experiencia). Créanme que es complicado de tratar – me temo que la palabra “revertir” como un husky siberiano teme la palabra “baño” después de que implementé la reversión de MSI en C ++. No es lo más divertido que he tenido, pero finalmente funcionó correctamente. Si desea que su configuración sea sin demasiadas dependencias, C ++ es el camino a seguir, y como todos sabemos, no es trivial. Las soluciones preparadas admiten la reversión de la caja; es una tarea fácil de ganar solo con un poco de lectura y búsqueda para habilitarlas. Complejidad sí, pero estás en un terreno más sólido. Y, lo que es más importante: una vez que ocurre un error oscuro en una máquina japonesa, podemos trabajar para solucionarlo en la comunidad, o un proveedor externo necesita ordenarlo.

  • Después de todas esas “observaciones generales”, en un nivel puramente técnico, las acciones personalizadas en Windows Installer son muy complejas en cuanto a implementación , progtwigción , acondicionamiento y retrotracción , y por lo tanto deben usarse cuando sea absolutamente necesario (a menudo para cosas de adopción temprana). Una complejidad adicional son los requisitos de tiempo de ejecución , por ejemplo, dependencias en versiones específicas del tiempo de ejecución de .NET o PowerShell o instalches de ejecución de Installscript (lenguaje de scripts de Installshield; tenía una dependencia de tiempo de ejecución, pero esto se resuelve en gran parte ahora, solía ser un problema )

  • Los errores de los requisitos de tiempo de ejecución faltantes pueden ser una bola de pelo enorme para tratar, con ganancia cero . Por este motivo, solo uso la mínima dependencia de C ++ dll o Installscript cuando realizo acciones personalizadas. Sucede que uso VBScript o JavaScript para acciones personalizadas de solo lectura en la secuencia de la interfaz de usuario . Estos simplemente recuperan datos y no hacen cambios en el sistema. Estos son los únicos tipos de acciones personalizadas que no son propensas a errores. Sin embargo, se deben configurar para que se ejecuten sin verificar los códigos de salida (para evitar que se desencadenen o se cancelen en una configuración que se está ejecutando, a menudo en el modo de actualización principal).
  • Además: Windows Installer aloja su propio motor de tiempo de ejecución de secuencias de comandos, para que sepa que sus scripts activos (VBScript, Javascript, etc.) pueden ejecutarse a menos que su sistema de destino esté realmente descompuesto (no hay un tiempo de ejecución faltante en un sistema normal). Esto está en contraste con las acciones personalizadas del código administrado : es totalmente posible que los sistemas objective no tengan tiempo de ejecución .NET en este punto (enero de 2018). Ahora esto cambiará en el futuro, ya que .NET se convierte en una función realmente incorporada y requerida en Windows (o en una versión mínima de la que aloja Windows Installer). Todavía existen problemas con el código de acción personalizado administrado que falla por razones extrañas, como la versión incorrecta de .NET que se usa para ejecutarlo, o la versión incorrecta del CLR que se está cargando y usando, etc … Tengo experiencia limitada aquí, pero los problemas son serios en mi opinión. Eventualmente, sin embargo, todos escribiremos acciones personalizadas de código administrado, creo. Sin embargo, aún usaría C ++ para los escenarios de distribución mundial.
  • Los scripts de Powershell son particularmente complicados para las acciones personalizadas, ya que aparentemente se han quedado sin proceso y no pueden acceder al objeto de sesión de MSI (fuente: experto de MSI, Chris Painter). Powershell también requiere que se instale .NET framework. Nunca usaría la secuencia de comandos Powershell para acciones personalizadas, ni siquiera para la implementación corporativa interna . Tu llamada. Solo como una “muestra”, aquí hay un experto en el campo que dice su opinión (elemento del blog que está envejeciendo, pero sigue siendo relevante si me lo preguntas): ¡No uses el código administrado para escribir tus acciones personalizadas!
  • Traté de escribir un resumen de los pros y los contras de los diferentes tipos de acciones personalizadas . Francamente, no estoy muy contento con él, pero aquí está: Windows Installer falla en Win 10 pero no en Win 7 usando WIX . ¿Con qué no estoy feliz? La recomendación de JavaScript para una cosa, la he usado rara vez, y aunque es un lenguaje mejor que VBScript, particularmente para el manejo de errores, he tenido muchos problemas al usar Javascript con MSI. Puede tratarse del problema que existe entre el teclado y la silla :-), pero creo que también hay algunos problemas reales con JavaScript. Intenta evitar el uso complejo de scripts. Para cosas simples como recuperar propiedades, parecen funcionar bien para mí. Sin embargo, los expertos en este campo son despiadados en las acciones personalizadas de los scripts: ¡no use vbscript / jscript para escribir sus acciones personalizadas! (Aaron Stebner), VBScript (y Jscript) MSI CustomActions suck (Rob Mensching – benevolencia de WiX).
  • Permítanme también agregar que la complejidad de la acción personalizada es ” tonta, complejidad conspiratoria “, no es algo divertido de tratar. Te muerde Gotchas. Descubrirá todos los errores que haya cometido a su debido tiempo: a medida que avanza (y luego tiene algunas explicaciones que hacer), a menudo no serán inmediatamente obvios (de repente surgen problemas al actualizar, aplicar parches, desinstalar, ejecuta su acción personalizada). erróneamente durante la reparación porque no está acondicionado adecuadamente y borra ciertas configuraciones de registro, la instalación silenciosa no funciona correctamente: deja la instalación incompleta porque la acción personalizada solo existe en la secuencia de la interfaz de usuario, hay errores de tiempo de ejecución en Windows XP que usted nunca probó su código de acción personalizado, hay cosas rotas en los sistemas de destino de las que no se escudó, alguien lo llama y le dice que su paquete no funciona con el directorio activo, su paquete no puede anunciarse, falla en todos los sistemas coreanos y japoneses, la autorreparación activa las advertencias de tiempo de ejecución y el acceso denegado para usuarios normales, etc.). No tendrá tiempo para arreglar esto correctamente una vez que lo golpee, y es probable que deba seguir con soluciones por debajo del estándar para adelantarse al siguiente obstáculo. Y no, yo no experimenté todo esto yo mismo. De hecho, descubrí la mayoría de estos problemas al arreglar los archivos MSI de terceros proveedores para la implementación corporativa. Realmente descubres una gran cantidad de posibles fonts de error cuando ves, comparas, revisas y adaptas cientos de paquetes a un estándar corporativo para implementación a gran escala. Honestamente, hay fallas y errores serios en todos los paquetes, excepto en los más simples. Y, obviamente, puedes ver lo que hiciste mal cuando hiciste esas configuraciones de vendedor unos años antes. ¿Y adivina qué encabeza la lista? Uso excesivo de acciones personalizadas cuando las construcciones incorporadas estaban disponibles.
  • Y para agregarlo a todo, la complejidad inherente de la implementación con su requerimiento de trabajar en cualquier máquina, en cualquier lugar y en cualquier estado, existe el problema de la tecnología MSI anti-patrones límite . Partes de la tecnología MSI que causan problemas repetidos de implementación porque no se comprenden bien y, a veces, son frágiles en el uso en el mundo real. Hay un breve resumen de esto en esta respuesta (hacia abajo): Cómo hacer un mejor uso de los archivos MSI (junto con una lista de los beneficios corporativos muy importantes de MSI – y un volcado aleatorio de problemas técnicos comunes vistos en real- paquetes mundiales ). Particularmente, el último enlace me pareció menos que ideal después de que lo escribí. Tómelo como lo que es: consejos desordenados del mundo real sin mucho más a su favor. Identifica demasiados problemas sin mostrar mucho en la línea de arreglos en los lugares.
  • Una parte sustancial de las llamadas de soporte de un software tienden a provenir de problemas observados durante el proceso de implementación . Como dice la historia: ” … no instalar correctamente su gran software puede estar cerca de ser el error más caro en el desarrollo de software. Nunca se puede esperar vender un software que nunca fue posible probar ” (de uno de las respuestas enlazadas arriba). Una mala acción personalizada a menudo está detrás de tales problemas.

  • Los usos de acción personalizados innecesarios más comunes que vemos son en mi opinión :

    • 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. Lo que necesita es un progtwig de arranque que pueda iniciar su configuración y sus requisitos previos en una secuencia. Las herramientas de implementación comercial como Advanced Installer e Installshield tienen características para esto, pero los frameworks gratuitos como WiX tienen soporte a través de su característica Burn , y también hay aplicaciones gratuitas de GUI como DOTNetInstaller (no probadas por mí) con este tipo de características.

    • Por favor, tome mi palabra en este caso particular: la ejecución de configuraciones incorporadas a través de una acción personalizada fallará eventualmente , por lo general de manera bastante inmediata. MSI es demasiado complicado en su progtwigción, suplantación, transacción, retrotracción y architecture de tiempo de ejecución general para que esto sea posible. Solo una transacción de MSI se puede ejecutar a la vez por diseño, y esto hace las cosas muy complicadas. Solía ​​ser que podía ejecutar archivos MSI incrustados como un concepto en MSI, pero esto estaba en desuso, no funcionaba correctamente. Debe ejecutar cada configuración en secuencia. La secuencia correcta Hay bootstrappers / chainers disponibles que le permitirán definir dicha secuencia de instalación. Aquí hay una respuesta que describe algunos de ellos (no dejes que el título de la pregunta te desanime – se trata de bootstrappers / chainers y otras consideraciones de implementación): Wix – Cómo ejecutar / instalar la aplicación sin UI .

6.2 Alternativas de acción personalizada

  • Las soluciones preparadas que se encuentran en WiX y otras herramientas como Installshield y Advanced Installer son probadas y, lo que es más importante, implementan un adecuado soporte de reversión , una característica que casi siempre falta en las implementaciones de acciones personalizadas, incluso en configuraciones de MSI de otro proveedor. Rollback es una función muy importante de MSI. No puede competir con la calidad entregada por una gran comunidad de usuarios con uso activo y pruebas en todo tipo de entornos. Haga uso de estas características.

  • Además de utilizar construcciones integradas de MSI o funciones personalizadas de WiX, a menudo se pueden evitar acciones personalizadas mediante pequeños cambios en el diseño de la aplicación, de modo que ya no se necesitan acciones personalizadas complejas . Veo las licencias como un ejemplo de cómo la implementación se puede simplificar para mejorar la confiabilidad.

    • Este es un punto muy importante, que a menudo se ignora. A veces, algunas horas de calidad o días de encoding y un poco de tiempo UAT / QA de calidad pueden evitar problemas de implementación a largo plazo. Ninguna cantidad de tiempo de soporte puede resolver los peores problemas de despliegue que pueda crear.

    • Esta respuesta proporciona una propaganda sobre la complejidad general de la implementación : Windows Installer y la creación de WiX (hacia abajo). La implementación es un “proceso de entrega” complicado con varios desafíos serios: 1) la naturaleza acumulativa de los errores de implementación , 2) la dificultad de una correcta depuración , y 3) la gama virtualmente ilimitada de factores externos y variables que afectan las máquinas objective en todo el mundo : La conclusión es que la implementación debe hacerse lo más simple posible para ser confiable. Hay tantos factores intermedios que te dejan con el progtwig favorito: el error intermitente . El enlace anterior se recomienda para una explicación más detallada.

6.3 Problemas avanzados de acción personalizada (más allá de los fallos de tiempo de ejecución)

  • Un problema de acción personalizado muy común es su progtwigción incorrecta e intentar modificar el sistema de acciones de modo inmediato “no elevadas”. Estos son defectos avanzados de diseño de MSI que no se reconocen de inmediato para las personas que ven una configuración que de lo contrario funcionaría.

  • Nunca inserte acciones personalizadas de modo inmediato después de InstallFinalize en InstallExecuteSequence de su MSI que intente modificar el sistema (lectura / escritura). Estas acciones nunca se ejecutarán si su configuración se implementa en modo silencioso a través de sistemas de implementación como SCCM (nuevamente, la última vez que revisé).

  • Nunca intente cambiar el sistema utilizando acciones personalizadas de modo inmediato activadas desde la GUI de configuración . Esto parecerá funcionar para los usuarios administradores, pero las acciones personalizadas de modo inmediato no son elevadas y, por lo tanto, los usuarios regulares no podrán ejecutarlas sin error. Además, cualquier cambio realizado en el sistema desde la GUI de MSI nunca se realizará cuando la configuración se ejecute en modo silencioso (entonces se omite toda la secuencia de la GUI). Esta es una falla de diseño de MSI muy seria : la instalación silenciosa e interactiva causa diferentes resultados. Este problema se menciona en la sección 10 sobre la instalación silenciosa así como en esta respuesta: ¿Cómo evito fallas de diseño comunes en mi solución de implementación de WiX / MSI? . La instalación silenciosa es una característica crucial para la implementación corporativa de su software. En las empresas con control de su implementación, TODA la implementación se realiza de forma silenciosa. Su GUI de configuración simplemente nunca se ve. Solo se me ocurren algunas excepciones, como ciertas implementaciones de servidores que pueden realizarse de forma interactiva, pero todo el software de escritorio y de cliente se implementa de forma silenciosa. No apoyar adecuadamente la instalación silenciosa es una deficiencia horrenda y un defecto de diseño de la configuración de MSI. Por favor, escucha este consejo. Es crucial para la aceptación corporativa de su software: recomendé que se descarte cierto software del sistema estándar porque su implementación es tan peligrosa para el sistema que simplemente no queremos manejarlo. La virtualización y la zona de pruebas ( APP-V , paquetes virtuales o máquinas virtuales) son grandes hoy precisamente debido a estos problemas ( aplicaciones y configuraciones incorrectas ).

  • Todas las acciones personalizadas que realizan cambios en el sistema deben insertarse en la “sección de transacción” de la secuencia de instalación. Esta transacción de Windows Installer (se piensa en la confirmación de transacción de la base de datos) se ejecuta entre las acciones estándar InstallInitialize e InstallFinalize en InstallExecuteSequence y se ejecuta con derechos elevados. Todos los cambios en el sistema se llevarán a cabo en esta transacción; cualquier otra cosa es errónea (pero desafortunadamente es bastante común). Todas las acciones personalizadas que se inserten aquí deben tener implementada una acción personalizada de reversión correspondiente, y esto debería deshacer los cambios realizados en el sistema en caso de que la instalación falle y se retrotraiga.

La idea de que las acciones personalizadas deben ser limitadas proviene del hecho de que es fácil escribir una acción personalizada implementada de manera deficiente. Una acción personalizada mal implementada es una que, en caso de falla de la instalación, no puede deshacer los cambios ya realizados en el sistema (es decir, la instalación de un servicio de Windows, por ejemplo).

Dicho eso, si se escribe una acción personalizada de manera que tenga una acción personalizada personalizada de reversión, entonces no creo que sea un problema.

El patrón que me gusta seguir es que por cada “acción personalizada” que creo que pueda necesitar (por ejemplo, FoobarCustomAction ), en realidad, consta de 3 acciones personalizadas:

  • FoobarCustomActionImmediate : esta es una acción personalizada inmediata que prepara 2 cargas útiles:
    • Primero, una carga útil para pasar a FoobarCustomActionDeferred , que dictamina al sistema la modificación de los cambios que se deben realizar.
    • Segundo, una carga para pasar a FoobarCustomActionRollback , que dicta cómo revertir el sistema alterando los cambios.
  • FoobarCustomActionRollback : es una acción personalizada de reversión progtwigda antes de FoobarCustomActionDeferred en secuencia, que usa la carga útil proporcionada por FoobarCustomActionImmediate para deshacer los cambios realizados por FoobarCustomActionDeferred en caso de una falla crítica.
  • FoobarCustomActionDeferred : esta es una acción personalizada diferida que hace que todo el sistema modifique los cambios en el sistema.

Al igual que muchas otras tecnologías, creo que siempre hay una manera de escribir código que no se puede mantener en WiX. Tomemos el ejemplo anterior, si esta es una acción personalizada que quiero usar en muchos instaladores diferentes, debería proporcionar a los desarrolladores un archivo .wxs que contenga un fragment que garantice que todas las acciones personalizadas necesarias se referencian y secuencen correctamente. Si, en cambio, el código de WiX simplemente se copia perezosamente a través de muchos instaladores diferentes, aumenta la posibilidad de que la acción personalizada se implemente de forma incorrecta. Es nuestro trabajo como desarrolladores ayudar a los consumidores de nuestro código a caer en la trampa del éxito, y creo que WiX lo proporciona a través del uso cuidadoso de fragment y wixlibs .

Pero el desarrollador del instalador tiene que preocuparse por tales cosas, ¡WiX no lo hace cumplir!