Forcer la mise à niveau d'un fichier modifié lors de son installation initiale

Question

Je travaille sur la fonctionnalité de mise à niveau de mon programme d'installation basé sur WiX.

Dans le cadre de l'installation, nous installons un fichier web.config, puis nous utilisons une action personnalisée pour mettre à jour les chaînes de connexion à l'intérieur du fichier.

Mais cela pose un problème lorsque nous exécutons notre mise à niveau. Nous aimerions avoir les RemoveExistingProducts planifiés après InstallFinalize car cela est plus efficace en termes de suppression et de réinstallation des fichiers qui n'ont pas changé. Mais cela laisse le fichier web.config d'origine en place au moment où Windows Installer tente de déterminer s'il doit le mettre à jour ou non. Sa dernière date de modification étant plus récente que sa date de création, Windows Installer décide de ne pas la mettre à jour (voir règles de version utilisées par Windows Installer). Mais nous avons besoin d’être mis à jour.

Une solution évidente consiste à modifier la planification de RemoveExistingProducts après InstallValidate - mais cela est inefficace et je ne pense pas que cela nous donnerait la possibilité de migrer les paramètres à partir de fichiers existants, si cela était nécessaire.

Avez-vous d'autres idées?

Answer 1

Il existe de nombreuses façons, aucune n’est idéale.

1: vous pouvez utiliser un fichier compagnon pour forcer la mise à jour du fichier en question. À condition que le fichier compagnon spécifié soit toujours mis à jour, cela peut être la solution. En gros, cela signifie que vous liez le fichier non versionné à la logique de mise à jour de version de son fichier compagnon (les fichiers sont mis à jour ensemble). Je n'ai jamais utilisé cela dans WIX, mais je pense que c'est aussi simple que d'ajouter l'attribut CompanionFile à un élément File et de pointer sur l'ID du fichier que vous souhaitez "version suivre". Dans le fichier MSI, cela ressemblera à quelque chose comme ceci:

2: vous pouvez utiliser une action personnalisée pour supprimer le fichier avant de calculer le coût du fichier (ou, mieux encore, le renommer en format de sauvegarde). Le problème est que si l'installation échoue, le fichier sera manquant. Si vous renommez le fichier au lieu de le supprimer, vous pouvez le restaurer en cas d'échec de la configuration via une action personnalisée de restauration. Parfois, j'utilise la table RemoveFile pour supprimer des fichiers lors de l'installation, mais selon le séquencement spécifié dans InstallExecuteSequence, cela peut ne pas fonctionner (la suppression doit avoir lieu avant que msi ne calcule le coût des fichiers).

3: Il y a ensuite l'approche du sledgehammer : définissez REINSTALLMODE = amus pour forcer le remplacement de tous les fichiers, quelle que soit leur version. Je ne devrais même pas mentionner cela car il est terriblement dangereux (vous pouvez écraser des fichiers système ou, sur les versions plus récentes de Windows, déclencher une erreur d’exécution désagréable car les fichiers sont protégés). Utilisez-le uniquement pour les tests de développement, et ne pensez pas que ce soit une solution rapide. Cela pose plus de problèmes qu'il n'en résout.

En variante, une approche acceptable peut être de définir REINSTALLMODE sur émeus (remplacer les fichiers de version plus anciens et identiques). Cela peut vous aider si vous ne souhaitez pas incrémenter les numéros de version, mais reconstruisez vos fichiers binaires, comme dans beaucoup de .NET. Mon hypothèse est que cela entraînera une toute nouvelle gamme de problèmes, mais dans la nature surtout les fichiers binaires différents mais de version identique si vous l'utilisez pour des versions publiques - un odeur de déploiement , le cas échéant. En tant qu’approche QA / DEV seulement, cela pourrait fonctionner. Mais sérieusement, pourquoi s'embêter? Il suffit d'incrémenter automatiquement la version de compilation des fichiers binaires et le problème est résolu de manière fiable.

Liens :

• Comment faire pour supprimer explicitement dll Pendant la mise à niveau majeure à l'aide de Wix Toolset

Answer 2

Seuls les douteux. Vous pouvez supprimer le fichier spécifique plus tôt avec une action personnalisée, mais assurez-vous de conditionner ce droit! Vous pouvez également spécifier une version pour le fichier afin que les règles de mise à niveau le traitent comme si vous remplaçiez un fichier non versionné par un fichier versionné, mais les correctifs peuvent nous inquiéter d'avoir la mauvaise version de ce fichier.

Answer 3

Ne pas utiliser une action personnalisée pour mettre à jour votre fichier de configuration est l’autre idée évidente. Au lieu de cela, demandez à WIX de faire la mise à jour via les extensions XML. Ex.

<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>

Ceci utilise une variable [SQLSERVERANDINSTANCE] qui doit être configurée à l'avance.