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

Question

Usamos wix para crear nuestras configuraciones. Para la actualización, utilizamos las principales actualizaciones como se muestra en this answer by Rob Mensching. (En las 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.

Consideremos por ejemplo el siguiente escenario:

• versión 1.0 de nuestro producto se libera, que contiene la versión 5.0 de un DLL thirdparty
• versión 1.1 de nuestro producto se libera, que contiene la versión 5.1 de la misma thirdparty dll
• se lanza la versión 1.2 de nuestro producto, bajando de categoría 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.

parecer con la lógica de actualización wix ligada arriba, la DLL 3rdparty desaparecerá al actualizar de liberación 01/01 a 01/02. 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.

Answer 1

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 hacer, incluyendo 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.

Answer 2

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

Answer 3

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

Answer 4

También encontramos este problema donde las DLL de versiones más bajas no se volvían a instalar en una actualización importante. Pensé que era extraño que el instalador decidiera qué archivos instalar basándose en el control de versiones de los archivos existentes, entonces completamente desinstaló todo, pero aún así solo instaló qué archivos se había determinado 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 por encima de la acción CostFinalize.

Sé que el documentation on MSDN recomienda colocar el RemoveExistingProducts después InstallValidate, y no estoy seguro de si ponerlo antes de la acción InstallValidate tiene ningún efecto secundario negativo para mejoras de menor importancia, pero hemos decidido realizar sólo mejoras importantes para nuestros productos entonces esta solución parece funcionar para nosotros.