Forzar una actualización de un archivo que se modifica durante su instalación inicial

Question

Estoy trabajando en la función de actualización para mi instalador basado en WiX.

Como parte de la instalación, estamos instalando un archivo web.config y luego utilizando una acción personalizada para actualizar las cadenas de conexión dentro del archivo.

Pero esto causa un problema cuando ejecutamos nuestra actualización. Nos gustaría tener los Productos RemoveExisting programados para después de InstallFinalize ya que esto es más eficiente en términos de no eliminar y reinstalar archivos que no han cambiado. Pero esto deja el archivo web.config original en su lugar en el momento en que Windows Installer intenta determinar si debe actualizarlo o no. Como su última fecha de modificación es más reciente que su fecha de creación, Windows Installer decide no actualizarla (consulte reglas de versiones que utiliza Windows Installer). Pero necesitamos que se actualice.

Una solución obvia es cambiar la programación de RemoveExistingProducts después de InstallValidate, pero esto es ineficiente y, además, no creo que nos brinde la oportunidad de migrar la configuración de los archivos existentes, en caso de que necesitemos hacerlo.

¿Alguna otra idea?

Answer 1

Hay muchas formas, ninguna es ideal.

1: puede utilizar un archivo complementario para forzar la actualización del archivo en cuestión. Siempre que el archivo complementario especificado siempre se actualice, este puede ser el camino a seguir. Básicamente, esto significa que vincula el archivo no versionado a la lógica de actualización de versión de su archivo complementario (los archivos se actualizan juntos). Nunca he usado esto en WIX, pero creo que es tan fácil como agregar el atributo CompanionFile a un elemento File y apuntar a la ID del archivo que desea "versión seguir". Dentro del archivo MSI se verá más o menos así:

2: puede usar una acción personalizada para eliminar el archivo antes de que el costo del archivo (o mejor aún, cambie el nombre a un formato de copia de seguridad). El problema es que si la configuración falla, faltará el archivo. Si cambia el nombre del archivo en lugar de eliminarlo, puede volver a colocarlo en caso de que la configuración falle mediante una acción personalizada de reversión. A veces uso la tabla RemoveFile para eliminar archivos en la instalación, pero dependiendo de la secuencia especificada en InstallExecuteSequence, esto puede no funcionar (la eliminación debe ocurrir antes de que msi haga el costo del archivo).

3: Luego está el enfoque de mazo : establezca REINSTALLMODE = amus para forzar la sobrescritura de todos los archivos independientemente de la versión. Ni siquiera debería mencionar esto, ya que es terriblemente peligroso (puede terminar sobrescribiendo los archivos del sistema, o en versiones más recientes de Windows desencadenar un desagradable error de tiempo de ejecución ya que los archivos están protegidos). Úselo solo para pruebas de desarrollo, y no piense que es una solución rápida. Causa más problemas de los que resuelve.

Como variación, un enfoque aceptable puede ser configurar el REINSTALLMODE en emus (reemplazar los archivos de versiones anteriores y las mismas). Esto puede ayudar si no desea incrementar los números de versión pero sigue reconstruyendo sus archivos binarios, como es el caso en muchos .NET. Sin embargo, supongo que esto causará una gama completamente nueva de problemas: más significativamente binarios diferentes pero versiones idénticas en la naturaleza si lo usa para lanzamientos públicos - un olor a despliegue si alguna vez hubo uno. Sin embargo, como enfoque de QA / DEV solo podría funcionar. Pero en serio, ¿por qué molestarse? Simplemente incremente automáticamente la versión de compilación de los archivos binarios y el problema se resolverá de manera confiable.

---

Enlaces :

• Cómo eliminar explícitamente dll Durante Majorupgrade usando Wix Toolset

Answer 2

Solo los dudosos. Puede eliminar el archivo específico antes con una acción personalizada, ¡pero asegúrese de condicionar esto correctamente! O bien, puede especificar una versión para el archivo para que las reglas de actualización lo traten como si reemplazara un archivo no versionado por uno versionado, pero luego los parches pueden inquietarse por tener la versión incorrecta de este archivo.

Answer 3

No use una acción personalizada para actualizar su archivo de configuración es la otra idea obvia. En su lugar, haga que WIX realice la actualización a través de las extensiones XML. Por ejemplo,

<Component Id="web.config" Guid="f12ff575-ad5f-47bc-a5c9-40b1e3a7f9f5" >
    <File Source="$(var.SrcPath)\web.config.config" KeyPath="yes" />

    <util:XmlConfig Id="AppSqlInstanceName"
                    File="[#web.config]"
                    Action="create"
                    ElementPath="//configuration/connectionStrings/add[\[]@name='YourStringKey'[\]]"
                    Name="connectionString"
                    Node="value"
                    Value="metadata=res://*/YourModel.csdl|res://*/YourModel.ssdl|res://*/YourModel.msl;provider=System.Data.SqlClient;provider connection string=&quot;data source=[SQLSERVERANDINSTANCE];initial catalog=DatabaseName;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework&quot;"
                    On="install"/>
</Component>

Esto está utilizando una variable [SQLSERVERANDINSTANCE] que debe configurarse de antemano.