Comment mettre en œuvre la mise à niveau du programme d’installation WiX?

Dans les versions les plus récentes (à partir de la version bêta 3.5.1315.0), vous pouvez utiliser l’ élément MajorUpgrade au lieu d’utiliser le vôtre.

Par exemple, nous utilisons ce code pour effectuer des mises à niveau automatiques. Il empêche les rétrogradations, en générant un message d’erreur localisé, et empêche également la mise à niveau d’une version identique existante (c.-à-d. Seules les versions inférieures sont mises à niveau):

Enfin, j’ai trouvé une solution – je la publie ici pour d’autres personnes qui pourraient avoir le même problème (toutes les cinq d’entre vous):

• Modifier l’ID du produit sur *

• Sous produit, append:

• Sous InstallExecuteSequence, ajoutez:

A partir de maintenant, chaque fois que j’installe le produit, il a supprimé les versions déjà installées.

Remarque: remplacez l’ID de mise à niveau par votre propre GUID

Voici le type de syntaxe que j’utilise pour les mises à niveau majeures:

Comme @Brian Gillespie a noté qu’il existe d’autres endroits pour planifier les RemoveExistingProducts en fonction des optimisations souhaitées. Notez que le PUT-GUID-HERE doit être identique.

L’élément Upgrade de l’élément Product, associé à une planification correcte de l’action, exécutera la désinstallation que vous recherchez. Veillez à répertorier les codes de mise à niveau de tous les produits que vous souhaitez supprimer.

Notez que si vous faites attention à vos versions, vous pouvez empêcher les utilisateurs d’installer par erreur une version plus ancienne de votre produit sur une version plus récente. C’est à quoi sert le champ Maximum. Lorsque nous construisons des programmes d’installation, nous définissons UpgradeVersion Maximum sur la version en cours de construction, mais IncludeMaximum = “no” pour empêcher ce scénario.

Vous avez des choix concernant la planification de RemoveExistingProducts. Je préfère le programmer après InstallFinalize (plutôt qu’après InstallInitialize comme d’autres l’ont recommandé):

Cela laisse la version précédente du produit installée jusqu’à ce que les nouveaux fichiers et les clés de registre soient copiés. Cela me permet de migrer les données de l’ancienne version vers la nouvelle (par exemple, vous avez basculé le stockage des préférences utilisateur du registre vers un fichier XML, mais vous souhaitez être poli et migrer leurs parameters). Cette migration est effectuée dans une action personnalisée différée juste avant InstallFinalize.

Un autre avantage est l’efficacité: s’il existe des fichiers inchangés, Windows Installer ne prend pas la peine de les copier à nouveau lorsque vous programmez après InstallFinalize. Si vous programmez après InstallInitialize, la version précédente est complètement supprimée, puis la nouvelle version est installée. Cela entraîne une suppression et une recopie inutiles des fichiers.

Pour les autres options de planification, voir la rubrique d’aide RemoveExistingProducts dans MSDN. Cette semaine, le lien est: http://msdn.microsoft.com/en-us/library/aa371197.aspx

Vous feriez peut-être mieux de poser cette question sur la liste de diffusion WiX-users .

WiX est mieux utilisé avec une bonne compréhension de ce que fait Windows Installer. Vous pourriez envisager d’obtenir le ” Guide définitif de Windows Installer “.

L’action qui supprime un produit existant est l’ action RemoveExistingProducts . Parce que les conséquences de ce qu’il fait dépendent de l’endroit où il est programmé – à savoir si une panne provoque la réinstallation de l’ancien produit et si les fichiers inchangés sont à nouveau copiés – vous devez le planifier vous-même.

RemoveExistingProducts traite les éléments de l’installation en cours, en faisant correspondre l’atsortingbut @Id à UpgradeCode (spécifié dans l’élément ) de tous les produits installés sur le système. Le UpgradeCode définit une famille de produits associés. Tous les produits qui ont ce UpgradeCode, dont les versions appartiennent à la plage spécifiée et où l’ UpgradeVersion/@OnlyDetect est no (ou est omis), seront supprimés.

La documentation de RemoveExistingProducts mentionne la définition de la propriété RemoveExistingProducts . Cela signifie que le processus de désinstallation du produit à supprimer reçoit cette propriété, dont la valeur correspond à l’ Product/@Id du Product/@Id pour le produit en cours d’installation.

Si votre installation d’origine n’incluait pas de UpgradeCode , vous ne pourrez pas utiliser cette fonctionnalité.

J’ai utilisé ce site pour m’aider à comprendre les bases de la mise à niveau WiX:

http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization

Par la suite, j’ai créé un exemple d’installation (installé un fichier de test), puis créé le programme d’installation de la mise à niveau (installé 2 exemples de fichiers de test). Cela vous donnera une compréhension de base du fonctionnement du mécanisme.

Et comme Mike l’a dit dans le livre d’Apress, “The Definitive Guide to Windows Installer”, cela vous aidera à comprendre, mais ce n’est pas écrit avec WiX.

Un autre site très utile était celui-ci:

http://www.wixwiki.com/index.php?title=Main_Page

J’ai lu la documentation WiX , téléchargé des exemples, mais j’avais toujours plein de problèmes avec les mises à jour. Les mises à niveau mineures n’exécutent pas la désinstallation des produits précédents malgré la possibilité de spécifier ces désinstallation. J’ai passé plus d’une journée à enquêter et j’ai découvert que le WiX 3.5 proposait un nouveau tag pour les mises à niveau. Voici l’utilisation:

Mais la principale raison des problèmes était que la documentation dit d’utiliser les parameters ” REINSTALL = ALL REINSTALLMODE = vomus ” pour les mises à jour mineures et de petite taille, mais cela ne signifie pas que ces parameters sont interdits pour les mises à niveau majeures . Vous ne devriez donc pas les utiliser avec des mises à niveau majeures.

Je suggère de jeter un coup d’œil au tutoriel d’Alex Shevchuk. Il explique la “mise à niveau majeure” via WiX avec un bon exemple pratique de From MSI to WiX, partie 8 – Mise à niveau majeure .

Une chose importante que j’ai ratée des didacticiels pendant un certain temps (volé sur http://www.tramontana.co.hu/wix/lesson4.php ) et qui a abouti aux erreurs “Une autre version de ce produit est déjà installée”:

* Les petites mises à jour signifient de petits changements apportés à un ou plusieurs fichiers pour lesquels la modification ne justifie pas la modification de la version du produit (major.minor.build). Vous n’avez pas non plus besoin de modifier le GUID du produit. Notez que vous devez toujours modifier le GUID du package lorsque vous créez un nouveau fichier .msi différent des précédents à aucun égard. Le programme d’installation garde une trace de vos programmes installés et les trouve lorsque l’utilisateur souhaite modifier ou supprimer l’installation à l’aide de ces GUID. L’utilisation du même GUID pour différents packages risque de perturber le programme d’installation.

Les mises à niveau mineures indiquent les modifications sur lesquelles la version du produit changera déjà. Modifiez l’atsortingbut Version de la balise Product. Le produit restra le même, vous n’avez donc pas besoin de modifier le GUID du produit mais, bien sûr, vous obtenez un nouveau GUID de package.

Les mises à niveau majeures dénotent des changements importants, comme le passage d’une version complète à une autre. Tout changer: atsortingbut Version, GUID de produit et de package.

J’utilise la dernière version de WiX (3.0) et je n’arrive pas à faire fonctionner ce qui précède. Mais cela a fonctionné:

Notez que PUT-GUID-HERE doit être identique au GUID que vous avez défini dans la propriété UpgradeCode du produit.

Ci-dessous travaillé pour moi.

Assurez-vous que le UpgradeCode dans le produit correspond à Id in Upgrade.

C’est ce qui a fonctionné pour moi, même avec la majeure note DOWN :