El instalador de Windows elimina el archivo versionado durante la actualización del producto, en lugar de degradarlo

Usamos wix para crear nuestras configuraciones. Para la actualización, utilizamos las principales actualizaciones tal como lo demuestra Rob Mensching en esta respuesta . (En versiones más nuevas de wix puede usar el elemento MajorUpgrade ). Normalmente, esto funciona bien. El producto anterior se elimina, luego se instala el nuevo producto.

Sin embargo, aparentemente lo anterior no es completamente equivalente a la desinstalación manual del producto anterior y la instalación manual del nuevo producto.

Considere por ejemplo el siguiente escenario:

  • se lanzó la versión 1.0 de nuestro producto, que contiene la versión 5.0 de una dll de terceros
  • se lanza la versión 1.1 de nuestro producto, que contiene la versión 5.1 de la misma dll de terceros
  • la versión 1.2 de nuestro producto es lanzada, degradando a la versión 5.0 de la DLL de terceros porque descubrimos que la nueva versión presentaba más problemas de los que resolvía.

Aparentemente con la lógica de actualización de wix vinculada anteriormente, el DLL de terceros desaparecerá al actualizar de la versión 1.1 a la 1.2. Una reparación es necesaria para restaurarlo.

¿Hay alguna otra manera de actualizar, que funcionaría para este escenario? Creo que lo que estoy buscando es una lógica de actualización que permita la degradación de los componentes, comportándose exactamente como si uno desinstalara manualmente el producto anterior y luego instalara manualmente el nuevo producto.

También encontramos este problema donde las DLL con versiones más bajas no se estaban reinstalando en una actualización importante. Pensé que era extraño que el instalador decidiera qué archivos instalar según el control de versiones de los archivos existentes, luego desinstalara todo por completo, pero que solo instalara qué archivos habían sido determinados para instalar antes de desinstalar el producto anterior. Parece que podría ser un error en Windows Installer …

Para solucionar este problema, movimos la acción RemoveExistingProducts sobre la acción CostFinalize .

Sé que la documentación en MSDN recomienda colocar RemoveExistingProducts después de InstallValidate , y no estoy seguro de si ponerlo antes de la acción InstallValidate tiene algún efecto secundario negativo para las actualizaciones menores, pero hemos decidido realizar solo actualizaciones importantes para nuestros productos, por lo que esta solución parece funcionar para nosotros

Comportamientos como este generalmente tienen que ver con la secuencia de RemoveExistingProducts . Si ocurre lo suficientemente tarde, Windows Installer se habrá dado cuenta de que hay una versión más nueva de .dll en la máquina, por lo que la versión 1.2 no necesita instalarlo. Sin embargo, cuando RemoveExistingProducts da como resultado la eliminación de .dll, nada lo vuelve a poner.

Cosas que probar, como cambiar la secuencia de RemoveExistingProducts y mentir sobre la versión de .dll en tu paquete 1.2 (informa un número de versión más alto que el malo). La desventaja de esto último es un impacto pobre en las reparaciones o parches, ya que el .dll siempre parece estar desactualizado.

No es óptimo, pero solucioné el problema al cambiar el nombre del dll de terceros y al cambiar el GUID en el nodo del componente asociado al archivo .wxs.

Intente progtwigr RemoveExistingProducts anteriormente, justo después de InstallValidate , y cambie el valor de la propiedad REINSTALLMODE a amus . De esta forma, el producto antiguo se eliminará por completo antes de que se copien los archivos del nuevo producto, y a modo forzará la reinstalación de los archivos.