Administrar archivos de configuración con WiX

Question

Tengo una aplicación con varios archivos que contienen parámetros de configuración y otros datos que cambian a medida que el usuario usa la aplicación. Estos archivos pueden cambiar con versiones más nuevas de mi software, pero el usuario también puede modificarlos (o pueden ser modificados por la aplicación). Básicamente, estoy buscando una solución para evitar que se sobrescriban los cambios de los usuarios en estos archivos, pero también una forma de instalar los archivos potencialmente actualizados cuando el usuario actualice mi software.

Con RPM en * NIX, podría usar la función% config para definir un archivo como archivo de configuración y RPM cambiaría el nombre del archivo existente (si existía) e instalaría el nuevo en una actualización (tal vez no ideal, pero podría vivir con algo así para WiX).

Me gustaría instalar mis archivos de configuración en un subdirectorio o incluso en un nombre diferente (por ejemplo, default.cfg) y luego usar el elemento <CopyFile> en WiX para copiar los archivos en sus ubicaciones correctas. De esta forma, los archivos predeterminados se eliminarían durante la instalación y se sobrescribirían en una actualización, pero los archivos de usuario reales seguirían siendo los mismos. Desafortunadamente con <CopyFile>, Windows Installer aún desea administrar (y eliminar) el archivo de destino.

También consideré usar la acción QtExec en WixUtilExtension para básicamente hacer "copy default.cfg reallocation.cfg" pero esto no funcionaría y es un poco hackeo.

¿Cuál es la forma correcta de manejar esto?

Answer 1

Creo que no hay una manera "limpia" de hacerlo, porque un proyecto msi debe poder desinstalarse completamente por diseño. Creo que la mejor manera de resolver esto es mediante el uso de una acción personalizada que ejecute un archivo por lotes y ponga su lógica de actualización de archivos de configuración en ese archivo por lotes. La acción personalizada se parece a esto (sólo partes pertinentes):

<Directory Id="MYDIR" Name="MyDir"> 
    <Component Id="update.cmd" Guid="YOUR-GUID"> 
     <File Id="update.cmd" Name="update.cmd" KeyPath="yes" 
       Source="source\update.cmd" /> 
    </Component> 
</Directory> 

<CustomAction Id='RunUpdate' Directory='MYDIR' 
     ExeCommand='[SystemFolder]cmd.exe /c update.cmd' Return='ignore'/> 

<InstallExecuteSequence> 
    <Custom Action='RunUpdate' After='InstallFinalize'>NOT Installed</Custom> 
</InstallExecuteSequence> 

Answer 2

Mi recomendación es por lo general para tener el contenido editable por el usuario en un archivo separado y gestionar que a través de la aplicación en lugar de la instalación. Eso también significa que el archivo separado es "contenido del usuario" y debe dejarse fuera de la instalación.

He encontrado tratando de hacer que la migración de datos de usuario declarativamente sea engañosamente difícil. Tratar de hacerlo en el momento de la instalación cuando necesita pensar en la instalación, desinstalación, reparación, parchado y reversión para todos esos casos solo lo empeora.

Por ejemplo, ¿qué hace el comportamiento de RPM en "reparar". Copie los datos del usuario fuera del camino y reemplácelos con un buen archivo? Eso es probablemente correcto 60% - 80% del tiempo. Y desinstale, ¿debería eliminarse el archivo? Eso es complicado si el usuario simplemente va a actualizar a la próxima versión.

Una vez más, es mejor dejarles decidir qué hacer con sus ajustes a la configuración. EN MI HUMILDE OPINIÓN.