¿Cómo debo manejar las actualizaciones de productos en un instalador de WiX?

Question

Tengo un instalador de WiX razonablemente grande (250 Mb más) y estoy tratando de encontrar una estrategia de actualización adecuada.

La mayoría de los archivos en el instalador no cambiarán y preferiríamos no tener que distribuir el paquete completo cuando solo uno o dos archivos han cambiado.

He examinado las actualizaciones mayores y menores y tengo entendido que se producirá una actualización importante si el ID del producto cambia, siempre que la ID de actualización permanezca igual y se puedan usar parches de actualización menores si ambos valores permanecen lo mismo.

Mi impresión es que una actualización menor usando un parche sería la mejor opción para manejar los casos donde solo unos pocos archivos cambian y solo para reconstruir todo el instalador cuando una cantidad sustancial de archivos cambia.

He probado esto usando "antorcha" para producir un archivo "wixmst" basado en las diferencias entre dos archivos "wixpdb", luego construyendo un parche a partir de eso. Sin embargo, descubrí que solo puedo parchar de una versión a otra (por ejemplo, 1.0.0 a 1.0.1, luego 1.0.1 a 1.0.2 pero no 1.0.0 a 1.0.2). ¿Es posible orientar una versión mínima para un parche y admitir cualquier versión anterior?

Answer 1

Los parches son un problema, así que prepárate para un montón mientras aprendes a dominarlo. Aquí hay otra estrategia que podría funcionar para usted. Divida su MSI en 2 MSI (Microsoft llama a esto Micropaquetes). Tenga un MSI base que contenga la mayor parte de su contenido que se espera que no cambie y un segundo MSI que sea mucho más pequeño y contenga los archivos que espera que sean de alta rotación.

Luego use Burn es un programa de arranque para manejar el encadenamiento entre ellos y desinstalarlos juntos. Esto es similar a lo que hace Visual Studio.

Ahora puede enviar grandes actualizaciones de su segundo MSI.

Answer 2

Creo que es posible aplicar un parche en el escenario que describió anteriormente, siempre que los parches no se puedan desinstalar. Un escenario de ejemplo sería:

1. Instalar MSI (v1.0)
2. Instalar MSP (v1.0 - v1.1)
3. desinstalación msp (de nuevo a v1.0) a continuación, instalar msp (v1 0.0 - v1.2)

Para obtener más información sobre los parches puedan instalar, consulte la documentación de Wix: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm y la documentación de Windows: http://msdn.microsoft.com/en-us/library/aa372102.aspx.

Tenga en cuenta que para crear parches desinstalables hay ciertas restricciones y debe estar en WiX 3.0 o superior.

Como mencionó Christopher, parchar puede ser un problema. He descubierto que, en muchos casos, mis gerentes pueden solicitar la posibilidad de realizar actualizaciones de parches cuando lo único que realmente quieren es que el usuario pueda actualizar sin tener que instalarlo primero, lo cual se puede lograr con una actualización importante.

Dicho esto, si tiene clientes que requieren muchas actualizaciones pequeñas que se descargan con frecuencia, entonces el parche puede valer la pena el esfuerzo adicional.

Answer 3

Aunque la respuesta de Christophers es asombrosa, ya que sugiere el arranque de wix, desaprobaría la ruta de hacer actualizaciones importantes para el paquete de "alta rotación".El problema es que después de que hayas hecho tu parche de arranque que internamente hace una actualización importante de tus libs volátiles en HighChurn.msi desde la versión v1.0 a la v1.1, el iniciador no volverá a instalar el anterior paquete de HighChurn.msi en v1.0.

Hay otra ruta: ciertamente puede crear parches que se dirijan al lanzamiento de su paquete principal. Dado lo que escribiste, no estoy del todo seguro, pero si tu parche 1.2 solo se puede aplicar a 1.1, entonces probablemente difiriste tu 1.2 solo contra 1.1 y no contra 1.0.

He aquí una guía ordenada cómo crear parches: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/

Siga esa guía, reemplazando hacer parches ([PatchFamily/@ sustituyen], que va a hacer todo aquello que invalidan v1.2 v1.1 enviado, por lo que básicamente se ven obligados a crear v1.2 parche v1.0 y no v1.1), y agreguen este indicador al elemento de parche para apuntar a la versión principal, aunque haya versiones superiores presentes: Patch/@MinorUpdateTargetRTM="yes". Siempre diferencie sus parches contra el instalador de versiones (HighChurn.msi v1.0), nunca contra el instalador que utilizó para un parche (HighChurn.msi v1.1).

Por supuesto, es posible que desee requerir una cierta actualización para los parches: un esquema de fixpack/servicepack bien planificado, por ejemplo, donde el parche 1.1.1 requiere el service pack 1.1 instalado en la versión 1.0.

Una última palabra sobre el parcheo de sus datos volátiles (estoy suponiendo bibliotecas versionadas aquí): es posible que desee tener un ojo en las librerías que básicamente podría reemplazar en el parche. Luego puede crear parches con muy pocos datos, solo dando a las bibliotecas modificadas una versión superior. Si aumenta la versión en todas sus bibliotecas, todas las bibliotecas se repararán, lo que generará parches más grandes. Esto podría requerir un flujo de trabajo de construcción un poco más complicado (Dios sabe que lo hizo por nosotros).