WiX: existe-t-il un moyen de dire quel fichier n'est pas écrasé lors d'une mise à niveau majeure?

Question

J'ai un grand programme dans WiX qui utilise un tas de MSI, C# programmes d'action personnalisés, UI, bootstrapper, vous l'appelez, c'est là.

J'ai ce problème: lorsque j'effectue une mise à niveau majeure, la version précédente n'est pas effacée. En d'autres termes, si je passe de la version 1.0.0.x à la version 1.1.0.x, Programmes & Les fonctions indiquent que les deux versions sont installées sur la machine.

Ceci est un problème commun, avec de nombreuses solutions ici sur SO. Aucun d'eux ne travaille pour moi - s'il y a un poste de SO à ce sujet, je l'ai essayé.

On m'a dit qu'il existe une relation un-à-un entre les composants d'une mise à niveau majeure. C'est-à-dire que pour chaque composant supprimé, un autre composant doit être ajouté. Quand ce n'est pas une relation de one-to-one, c'est quand l'ancienne version n'est pas supprimée - parce qu'il y a encore de vieux composants qui pendent.

Existe-t-il un moyen de déterminer quels composants sont suspendus? Comme, dans les fichiers journaux ou quelque chose? Si je pouvais déterminer ce que MSI a le problème, je pourrais être beaucoup plus proactif dans la résolution du problème.

---

EDIT:

Bien que je ne l'ai pas résolu le problème, grâce aux suggestions de M. Urman I peuvent être sur la bonne voie.

J'ai créé cette clé de registre, mais ... elle ne semblait pas faire quoi que ce soit. Cependant, je l'ai fait chercher mes journaux de désinstallation pour le mot « Disallow », et je trouve cette phrase 9 fois:

Disallowing uninstallation of component: {GUID-HERE} since another client exists. 

En outre, cette phrase apparaît avant chaque regroupement de l'expression « Rejeter »:

PROPERTY CHANGE: Adding INSTALLLEVEL property. It's value is '1'. 

Cela me donne quelque chose à faire. Cependant, je n'arrive pas à trouver les GUID qui sont mentionnés! Ils ne sont pas dans ma solution et ils ne sont pas consultables dans le registre. Outre la recherche dans le registre, existe-t-il un moyen (Windows 7 32 bits) de savoir à quel composant un GUID spécifique correspond?

Answer 1

On m'a dit qu'il existe une relation un-à-un entre les composants dans une mise à niveau majeure. C'est-à-dire que pour chaque composant supprimé, un autre composant doit être ajouté. Quand ce n'est pas une relation de one-to-one, c'est quand l'ancienne version n'est pas supprimée - parce qu'il y a encore de vieux composants qui pendent.

Ceci n'est pas strictement vrai. Il est tout à fait vrai de mises à niveau mineures, et dans certaines configurations (celles impliquant une fin RemoveExistingProducts) mises à niveau majeures sont tout aussi pointilleux. Mais les fonctions de mise à niveau majeures typiques ressemblent davantage à ce que l'utilisateur avait choisi pour désinstaller l'ancienne version, puis pour installer la nouvelle version. Commencez par vérifier vos hypothèses: assurez-vous d'avoir une mise à niveau majeure appropriée (vous avez modifié votre ProductVersion et votre code de produit, et avez les bonnes entrées dans votre tableau de mise à niveau, n'est-ce pas?). Puis diagnostiquer.

Comment identifier au mieux ce qui se passe? Dans mon expérience, les fichiers journaux sont votre meilleur pari. Étant donné que l'ancienne version est désinstallée indirectement, vous ne pouvez pas utiliser les lignes de commande pour la journaliser. Par conséquent, définissez Logging policy en créant ou en définissant la valeur de Registre suivante. (Enlevez-le plus tard si vous voulez revenir au réglage.)

HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ Installer
Valeur (Reg_SZ): Connexion
données: voicewarmup

Ensuite, exécutez votre mise à jour majeure, trouver le fichier journal approprié cela a été généré en % temp%. (Pensez à nettoyer% temp% à l'avance pour faciliter la recherche ou à trier par date.) Recherchez particulièrement la désinstallation (que vous pouvez identifier par ProductVersion ou la présence de UPGRADINGPRODUCTCODE). Je chercherais surtout des lignes comme Désallouant la désinstallation du composant ... qui contient un GUID de composant. Une fois que vous avez ce GUID, vous devez déterminer quel composant il est, et comment il est entré dans son état actuel.

Vous pouvez examiner manuellement vos fichiers .msi construits (avec un outil comme Orca) pour trouver le composant, mais peu d'outils vous diront tous les clients. Le produit de mon employeur est livré avec un outil d'assistance appelé InstallShield Msi Sleuth qui peut lister tous les produits installés référençant un code de composant, ou vous pouvez construire votre propre de MsiEnumProducts ou Installer.ComponentClients. Vous ne pouvez pas effectuer une recherche directement dans le registre, car Windows Installer stocke les GUID dans un format compressé ou compressé. Puis identifier le "pourquoi" pourrait être la partie la plus difficile. Ou il peut s'agir d'un nombre de références de DLL partagée incorrect, en particulier si vous ne l'avez rencontré que sur un ordinateur de test ayant vu des versions non publiées de votre produit.

En alternative, mais uniquement pour une mise à niveau mineure ou une petite mise à jour, vous pouvez définir EnforceUpgradeComponentRules Policy. Cela permet de révéler les problèmes au fur et à mesure que vous les rencontrez, plutôt que de laisser Windows Installer faire de son mieux pour continuer malgré tout.