metaetiqueta - wix head tag
El instalador de Windows elimina el archivo versionado durante la actualización del producto, en lugar de degradarlo (4)
Comportamientos como este generalmente tienen que ver con la secuenciación de RemoveExistingProducts . Si ocurre lo suficientemente tarde, el instalador de Windows habrá descubierto que hay una versión más reciente de la .dll en la máquina, por lo que la versión 1.2 no necesita instalarla. Sin embargo, cuando RemoveExistingProducts da como resultado la eliminación de la .dll, nada lo devuelve.
Se puede intentar cambiar la secuencia de RemoveExistingProducts y mentir acerca de la versión de .dll en su paquete 1.2 (informe un número de versión más alto que el malo). La desventaja de este último es el bajo impacto en las reparaciones o parches, ya que el .dll siempre parece desactualizado.
Usamos wix para crear nuestras configuraciones. Para la actualización, utilizamos actualizaciones importantes como lo demuestra Rob Mensching en esta respuesta . (En las versiones más nuevas de wix puede usar el elemento MajorUpgrade ). Esto normalmente funciona bien. El producto anterior se elimina y, a continuación, se instala el nuevo producto.
Sin embargo, al parecer, lo anterior no es completamente equivalente a desinstalar manualmente el producto anterior y luego instalarlo manualmente.
Considere, por ejemplo, el siguiente escenario:
- Se lanza 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 del mismo dll de terceros.
- Se lanzó la versión 1.2 de nuestro producto, volviendo a la versión 5.0 de dpart de thirdparty porque descubrimos que la nueva versión presentaba más problemas de los que resolvió.
Al parecer, con la lógica de actualización de wix vinculada anteriormente, la dll de 3rdparty desaparecerá cuando se actualice de la versión 1.1 a 1.2. Una reparación es necesaria para restaurarlo.
¿Hay otra forma de actualizar, que funcionaría para este escenario? Supongo que lo que busco es una lógica de actualización que permita degradar los componentes, comportándose exactamente como si uno desinstalara manualmente el producto anterior y luego lo instalara manualmente.
Es subóptimo, pero solucioné el mismo problema cambiando el nombre de la DLL de terceros y cambiando el GUID en el nodo del componente asociado con él en el archivo .wxs.
Intente programar RemoveExistingProducts antes, justo después de InstallValidate , y cambie el valor de la propiedad REINSTALLMODE a amus . De esta manera, el producto anterior se eliminará por completo antes de que se copien los archivos del nuevo producto, y a modo forzará la reinstalación de los archivos.
También encontramos este problema donde las DLL de versiones inferiores no se volvían a instalar en una actualización importante. Pensé que era extraño que el instalador decidiera qué archivos instalar en función de la versión de los archivos existentes, luego desinstalara todo por completo, pero aún así solo instalaría qué archivos se habían determinado instalar antes de desinstalar el producto anterior. Esto 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 que colocarlo antes de la acción InstallValidate tenga efectos secundarios negativos para pequeñas actualizaciones, pero hemos decidido realizar solo actualizaciones importantes para nuestros productos, por lo que esta solución Parece funcionar para nosotros.