código - Administrar archivos de configuración con WiX

agrega un código de encabezado meta tags en 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 como esto 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 a 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é utilizar la acción QtExec en WixUtilExtension para básicamente hacer "copy default.cfg reallocation.cfg", pero esto no funcionaría y es un truco.

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

Answer 1

Creo que no hay una forma "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 ve así (solo partes relevantes):

<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 generalmente tener el contenido editable del usuario en un archivo separado y administrarlo 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 que tratar de hacer la migración de datos de usuario declarativamente es 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 dejar que decidan qué hacer con sus ajustes a la configuración. EN MI HUMILDE OPINIÓN.