Plusieurs programmes d'installation msi installant le même répertoire

Question

J'ai deux installateurs msi, un pour le produit A construit avec InstallShield et un pour le produit B construit avec WiX. Le produit B était censé fonctionner au-dessus du produit A, mais récemment un certain code X a été migré de B vers A.

Lors d'une nouvelle installation, aucun problème ne se posait. Supposons cependant que sur un serveur j'ai installé A.1 et B.1 (.1 = version 1), où X est installé via B. Et supposons que je veuille installer A.2, qui contient maintenant X.

Le code X sera-t-il mis à jour? Que se passe-t-il si j'essaie de désinstaller A.2 ou B.1? Est-ce autorisé? Comment puis-je y parvenir?

Answer 1

Cela dépend en grande partie de certaines choses que vous n'avez pas clairement indiquées, alors allons-y un peu. Je suppose que depuis la version 1, tous les fichiers sont uniques entre les installateurs, ou sont correctement partagés et ne sont pas pertinents pour le code dont vous parlez de la migration (donc peut être ignoré pour cette question).

Cas 1: Le code X migre entre les DLL, par ex. A installe a.dll; B installe b.dll et le code passe de b.dll à a.dll

Dans ce cas, en supposant qu'il n'y ait pas de chaînes d'appel entre les deux produits, vous n'avez rien de spécial à faire. Il suffit d'avoir A.2 remplacer a.dll avec la prochaine version, et B.2 remplacer b.dll avec la prochaine version. Il n'y a aucune inquiétude concernant l'ordre d'installation ou la propriété multiple des DLL.

Cette approche devrait fonctionner avec n'importe quel type de mise à niveau, à condition que la version de DLL permette le remplacement correct des DLL. S'il existe une interface publiée (telle qu'une classe COM), il peut y avoir un ordre requis à la mise à jour pour s'assurer que b.dll renonce à la référence d'enregistrement avant que a.dll ne le prenne, mais ces modifications violent le composant règles.

Cas 2: La DLL du code X migre entre les programmes d'installation, par ex. B installe c.dll et cette DLL sera maintenant installée par A

Dans ce cas, votre succès dépendra de la qualité de votre création initiale. Si c.dll est installé par son propre composant et est marqué comme partagé, vous pouvez ajouter ce composant à A (correspondant à ses paramètres), et une mise à niveau fonctionnera sans problème dans l'un ou l'autre ordre. Si vous installez A.2 en premier, cela ajoutera au nombre de références, de sorte que l'installation de B.2 désoriente mais ne le supprime pas. Si vous installez B.2 en premier, il supprimera temporairement c.dll, mais l'installation de A.2 le restaurera. La désinstallation fonctionnera de la même façon, en suivant les décomptes de référence et en les supprimant si nécessaire.

Mais cela suppose une mise à niveau majeure. Si vous utilisez une mise à niveau mineure (qu'elle soit fournie en tant que .msp ou .msi), vous vous trouvez dans un scénario beaucoup plus difficile. Pour que le chemin de mise à niveau de B soit propre, il doit conserver le composant c.dll et choisir une autre approche pour supprimer c.dll. Cependant, toutes les approches que je connais entrent en conflit avec l'installation d'une copie exacte du même composant au même endroit. Dans ce cas, l'installation de B.2 en premier devrait fonctionner, mais l'installation en seconde peut supprimer c.dll.

Si des mises à niveau mineures peuvent fonctionner correctement, vous devrez peut-être également prendre en compte le cas d'une désinstallation de correctif, mais comme elles ne le peuvent pas, je ne le couvrirai pas ici.