Eliminar un GUID = "" componente instalado con WiX

Question

He arruinado mi instalador basado en WiX en varios servidores para que ya no elimine archivos o componentes (o incluso otras características) durante una desinstalación. El registro de MSI muestra que PreviouslyPinned = 1 en todos los componentes que no se desinstalarán.

No tengo nada de lujos como usar el conteo de SharedDll o incluso componentes compartidos entre diferentes instaladores.

Creo que lo he rastreado hasta una revisión particular de mi código WiX. Hice un par de cosas estúpidas. I (involuntariamente) creado un componente no administrado con un espacio en blanco Guid

<Component Id="file.ext" Guid=""> 
    <File .../> 
<Component> 

y también he cambiado la ubicación del archivo de otro componente y Id (pero no Es Guid). Todos los componentes presentes en las revisiones anteriores muestran PreviouslyPinned = 1 y no se desinstalarán, y los nuevos componentes agregados después de esta revisión se instalarán/desinstalarán correctamente.

¿Cómo puedo hacer que mi instalador vuelva a la normalidad y eliminar estos componentes previamente fijados?

Answer 1

Windows Installer realmente admite el concepto de GUID en blanco. Significa "instalar, pero no registrar el componente": http://msdn.microsoft.com/en-us/library/aa368007(VS.85).aspx (la entrada ComponentId explica lo que sucede con un GUID nulo).

Acabo de probar con WIX y parece respetar una entrada de GUID en blanco (es decir, no se genera automáticamente guid). Recuerde la regla 1: 1 entre ruta absoluta/ruta de la clave y GUID:

• Si cambia el GUID, una nueva ruta absoluta se debe utilizar para la trayectoria de sus componentes principales.
• Si cambia la ruta absoluta (por ejemplo, cambiando el nombre de un archivo o moviéndolo), debe cambiar el GUID.

En resumen, la referencia recuentos GUID del componente de ruta de instalación clave, no el archivo - que puede moverse, pero entonces el archivo tiene una nueva identidad a través de un nuevo GUID (pensar en dos archivos con el mismo nombre en carpetas diferentes: son archivos diferentes, identidades diferentes).

Limpiar mal El recuento de referencias GUID puede ser un poco desordenado. Encuentro que si puedo cambiar el nombre del archivo que efectivamente elimina el problema. También genero un nuevo guid y, por lo tanto, rompo el enlace al recuento de referencias del antiguo guid. También puede cambiar el nombre de la carpeta de instalación (lo que idealmente significaría que todos los GUID de componente deberían cambiarse también). El concepto de tabla RemoveFile se puede utilizar para eliminar archivos en la instalación y/o desinstalación que no se hayan registrado como componentes (por ejemplo, archivos generados).

Answer 2

Cambiar la identificación del componente y usar un GUID válido debería hacer las cosas bien.

Answer 3

La respuesta corta es:

Sí, utilizando componentes MSI sin GUID es una especie de método de copia por lotes. Copia y olvida. Por supuesto, debe agregar una sola cosa: eliminar todos los archivos antes de cada overinstall o uninstall (condición "REINSTALL o PATCH or REMOVE") o Major Upgrade. Sin eso, realmente no tiene sentido. Puede hacerlo en una acción personalizada, incluso con CMD.exe/c RD/S/Q .... (Por supuesto, el código personalizado es más elegante que este)

Si lo hace bien, puede lograr tener configuraciones bastante simples sin todas las trampas, normalmente MSI lo tiene. Por supuesto, es más fácil si elimina recursivamente un directorio completo que archivo por archivo.

No lo he intentado todavía, pero voy a: tener componentes "dinámicos" sin GUID y componentes normales y luego proporcionar un parche. En teoría, esto debería funcionar y esta sería una buena solución para una serie de problemas de parches que resultan de conjuntos de archivos altamente cambiantes entre parches.

Answer 4

1. De hecho, los componentes sin GUID son el verdadero método de "vinculación de archivos dinámicos" que a menudo achacan erróneamente varias herramientas o personas.

Otros "caminos": 2. Generación de GUID es automáticamente sólo un paso de automatización (pero por supuesto, parte de toda buena infraestructura de acumulación configuración :-) En mis ojos no es dinámica, ya que si lo haces de forma dinámica, lo haces mal:

2a. Generación de GUID que son completamente aleatorios cada vez => algoritmo erróneo

2b. Generar GUIDs solo la primera vez que se crea un componente y haber implementado el reconocimiento inteligente de "diff" para que se empaqueten los nuevos recursos en un nuevo componente => El único método de árbol de archivos de trabajo que funciona. Pero puede hacer mucho mal aquí ... Es para expertos.