2011-04-14 20 views
8

Hemos creado el instalador WIX para nuestra aplicación. El problema al que nos enfrentamos es: Hemos definido dos acciones personalizadas diferentes (por ejemplo, ActionForInstall y ActionForUninstall) que queremos realizar en el siguiente caso: ActionForInstall: debe ejecutarse durante la instalación, actualización del producto, modo de mantenimiento (para reparar y modificar) ActionForUninstall : Debería ejecutarse solo para la desinstalación.Realizar acciones personalizadas según el modo - WIX

Pero no podemos establecer el estado correcto. Puede consultar el código:

<Custom Action=ActionForInstall After='InstallFinalize' > 
    (NOT Installed) OR (Installed AND ((MaintenanceMode = "Modify") OR (MaintenanceMode = "Repair")) AND (NOT (MaintenanceMode = "Remove"))) OR ((UPGRADINGPRODUCTCODE) AND NOT(REMOVE ~= "ALL")) 
</Custom> 
<Custom Action=ActionForUninstall Before='InstallFinalize'> 
    Installed AND NOT UPGRADINGPRODUCTCODE 
</Custom> 

Háganos saber lo que hemos hecho mal. El código anterior está llamando a InstallFinalize incluso para la desinstalación.

+1

hoja de trucos de utilidad: http://www.flexerasoftware.com/webdocuments/PDF/IS-CHS-Common-MSI-Conditions.pdf. Me gusta deshabilitar las acciones personalizadas para correcciones de parches de MSI agregando NOT PATCH a la lista existente de condiciones, así como NOT UPGRADINGPRODUCTCODE para deshabilitarlas también para las principales actualizaciones. –

Respuesta

10

Usted puede tratar estas enfermedades:

ActionForInstall:

REMOVE <> "ALL" 

ActionForUninstall

REMOVE = "ALL" 
+0

Dependiendo de dónde está programada la acción personalizada y cómo se realiza la desinstalación, la condición ELIMINAR = "TODO" puede fallar. Por ejemplo, al hacer una/x para la desinstalación, la propiedad ELIMINAR se establece de inmediato. Pero cuando se realiza una operación de mantenimiento y se selecciona Desinstalar, la propiedad ELIMINAR no se establece hasta mucho después del cálculo del costo. Solo algo de lo que debes estar consciente. Sigo manteniendo que es mejor crear condiciones basadas en estados de componentes. –

+0

@christopher Tienes razón ... pero estamos en un horario apretado y no tenemos ningún experto en wix ... lo que dices puede requerir más esfuerzo para comprenderlo e implementarlo. Así que estamos usando una solución dada por @Cosmin – vrajs5

+0

Ver mi comentario agregado a la pregunta anterior sobre mejoras importantes e instalaciones de parches. Estos tipos de instalación utilizan la misma secuencia de instalación que la instalación principal, el mantenimiento y la desinstalación.A menudo es beneficioso condicionar sus acciones personalizadas para que no se ejecuten durante estos tipos de instalación. –

5

Por lo general, las condiciones que utilizan propiedades de nivel de productos como No instalado y REMOVE = "ALL" Don' t escala a tus expectativas. Por lo general es mejor utilizar los estados de acción componente, tal como

$ ComponentName = 3 < - componente que se instala localmente

$ ComponentName = 2 < - componente fue instalado previamente y ahora se está quitando

Este generalmente cubrirá todos sus escenarios de instalación, desinstalación, mantenimiento, reparación y actualización.

Puede hacer cosas similares para las características utilizando el operador "&", pero generalmente el uso de componentes "$" es mejor ya que los componentes son físicos y pueden asociarse a una o más características que son lógicas.

Y si realmente desea llevarlo al siguiente nivel, sus acciones personalizadas podrían (deberían) ser impulsadas por datos usando una combinación de clave externa a la tabla Componente. En este escenario, su acción personalizada siempre se activa y luego consulta las tablas y evalúa los estados de acción del componente para decidir qué operaciones deben programarse.

Conditional Statement Syntax (Windows)

Cuestiones relacionadas