actualización importante wix no instalar todos los archivos
major-upgrade (5)
Tengo un proyecto WiX muy simple (versión 3.7) que instala algunos archivos (un programa .NET versión 6.0.0.0). Estoy listo para lanzar una nueva versión 6.0.1.0 usando la funcionalidad MajorUpgrade en WiX.
Mantengo el UpgradeCode igual en el elemento Product y cambio la versión de 6.0.0.0 a 6.0.1.0
<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me"
UpgradeCode="$(var.TheUpgradeCodeGUID)">
En una máquina con 6.0.0.0 instalado, ejecuto el nuevo instalador.
La eliminación de la versión anterior 6.0.0.0 se ejecuta correctamente (se están eliminando todos los archivos instalados), pero cuando el instalador continúa instalando la nueva versión, faltan 2 archivos: una DLL de terceros y un EXE de terceros (que no tienen ha sido cambiado) no están siendo reinstalados.
<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
<File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
<File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>
Todos los demás archivos en <ComponentGroup> (algunos modificados, algunos no modificados, incluidos otros DLL de terceros) se están instalando correctamente durante la actualización principal.
Si hago clic en "reparar" después de la actualización principal, vuelven a aparecer los 2 archivos faltantes. Además, si instalo la versión 6.0.1.0 por primera vez (sin actualización, pero la primera instalación en una máquina limpia), entonces esos 2 archivos se instalan directamente y normalmente. (probado en varias máquinas Windows (XP, 7 y 8)
¿Alguien tiene alguna sugerencia de lo que está mal y cómo solucionarlo?
El archivo de registro proporcionado muestra que las versiones más recientes de algunos archivos que ya están en la máquina:
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists
He visto este problema con este actualizador en el pasado. Christopher tiene razón. El actualizador actualizó sus archivos pero no le dijo al MSI (no actualiza el MSI, que no es lo correcto). El nuevo MSI piensa que las cosas más nuevas están en la máquina, elige no instalar sus archivos, pero durante la actualización, el paquete anterior elimina los archivos (no se da cuenta de que las versiones son más nuevas). Dado que el nuevo instalador optó por no instalar los archivos, terminará sin nada ... hasta la reparación.
Para solucionar el problema, debe mover su acción RemoveExistingProducts más tarde. Si está usando el elemento MajorUpgrade, entonces Schedule=''afterInstallExecute'' o Schedule=''afterInstallFinalize'' deberían hacer el truco. Tendrá que ser más cuidadoso con las Reglas de los Componentes .
Además, en mi humilde opinión, el proveedor externo no debe actualizar los archivos fuera del MSI. Su decisión es forzar a su producto en una forma particular de actualización.
El error aún existe en el instalador 5.0 y sigue siendo un problema. La solución para colocar RemoveExistingProduct después de InstallFinalize no es una solución para nosotros. Forcé la actualización por configuración de propiedad en el archivo único.
Esta solución funciona para nosotros ahora.
En versiones anteriores de Windows Installer, el problema se documenta aquí:
https://support.microsoft.com/en-us/kb/905238
La lista de productos afectados indica que se corrigió en el motor MSI 4.0 y versiones posteriores. El uso de 4.5 redistribuible antes de realizar instalaciones debería ayudar, si corresponde a la versión del sistema operativo.
Tenía otra solución para este problema, pero la respuesta anterior sin duda me indicó la dirección correcta. A los DLL en mi proyecto .NET se les asignó un número de versión inferior al de mi instalación anterior. Ir a los archivos AssemblyInfo.cs e incrementar el tercer octeto de 0 a 1 lo resolvió. Wix ahora reconoció los DLL como más nuevos.
[assembly: AssemblyVersion("1.0.1.*")]
Un archivo de registro ayudaría. Mi conjetura es que se basa en donde ha programado RemoveExistingProducts. He visto situaciones en las que Costing descubre que un archivo que se está instalando es el mismo que el que ya está instalado y decide no instalarlo. Entonces ocurre la actualización principal y terminas sin tener el archivo. La reparación funciona porque el archivo no está allí y el costo se da cuenta de que se debe instalar.