Mise à jour des résultats d'installation à double entrée pour le logiciel installé (FindRelatedProducts pas exécutées)

J'essaie d'effectuer une mise à jour majeure avec mon installateur MSI avec une installation silencieuse . Le programme d'installation fonctionne déjà correctement lors de l'utilisation d'une installation normale avec une interface utilisateur complète. Dans ce cas, l'ancien produit est désinstallé car l'action FindRelatedProducts (à partir de la séquence de l'interface utilisateur de FolderForm) détecte ma version précédemment installée.Mise à jour des résultats d'installation à double entrée pour le logiciel installé (FindRelatedProducts pas exécutées)

Lorsque le commutateur/qr pour msiexec est utilisé pour supprimer les dialogues et la nécessité d'une interaction utilisateur (essentiellement la réutilisation des paramètres de la dernière version), il échoue:

MSI (s) : Doing action: FindRelatedProducts 
Action FindRelatedProducts. Searching for related applications 
Action start FindRelatedProducts. 
MSI (s) : Skipping FindRelatedProducts action: already done on client side 
Action ended FindRelatedProducts. Return value 0.

En conséquence, il y a deux entrées qui apparaissent dans le dialogue logiciel installé de Windows - un pour l'ancienne et la nouvelle version, donc dans ce cas, l'ancienne version n'a pas été désinstallée/supprimée.

Existe-t-il un autre commutateur de commande msiexec que je pourrais utiliser et qui exécuterait toujours l'action FindRelatedProducts? Pourrait-il être intégré ailleurs pour qu'il soit exécuté dans une installation aussi silencieuse?

Source

2010-01-04 marco4net

Est-ce que votre installation précédente était dans un contexte différent (par utilisateur ou par machine) que l'installation silencieuse? MSI n'est pas capable de désinstaller une installation par machine lorsque vous installez par utilisateur et vice versa. C'est une limitation technique avec laquelle vous devez vivre. –

Merci pour votre réponse, Divo. Le contexte devrait être le même, seul le niveau de l'interface utilisateur est différent (5 contre 4). Mais ce que je peux voir est que cette action n'est pas exécutée parce que les boîtes de dialogue ne sont pas montrées. Il serait déclenché avec DoAction pour FolderForm NextButton, mais ce n'est pas visible et exécuté avec le niveau réduit de l'interface utilisateur. D'un autre côté, lorsque FindRelatedProducts doit être vérifié et déclenché à nouveau, il est ignoré (comme indiqué dans l'extrait de journal ci-dessus) car il a été "déjà fait du côté client". Donc, ici, pour les deux niveaux d'interface utilisateur, la même chose est exécutée. – marco4net

J'ai trouvé un moyen de résoudre le problème et la mise à niveau est effectuée comme prévu.

Lors de son lancement avec /qb commutateur pour msiexec, FindRelatedProducts est exectuted et la mise à niveau fonctionne comme prévu.

Je n'ai pas trouvé de meilleure spécification ou explication sur les différents niveaux d'interface utilisateur et les implications sur l'exécution, mais il pourrait être assez d'informations pour déboguer et résoudre des problèmes similaires. Le commutateur/qr semble déclencher le saut: "Ignorer l'action FindRelatedProducts: déjà effectuée côté client".

Nous vous remercions de votre soutien!

Source

2010-01-05 09:46:51 marco4net

Vous semblez avoir mis l'accent sur un symptôme plutôt que sur le problème réel. FindRelatedProducts ne doit s'exécuter qu'une seule fois tant que les deux choses suivantes sont vraies: la propriété action de chaque entrée de mise à niveau est une propriété publique (ALL_CAPS) et le nom de cette propriété est répertorié dans la propriété SecureCustomProperties. Lorsque ces deux conditions sont vraies, la séquence d'interface utilisateur doit d'abord définir la propriété d'action, sa valeur doit la rendre intacte à la séquence d'exécution et RemoveExistingProducts doit traiter et supprimer les codes de produit associés répertoriés dans cette propriété. (Bien sûr, exécuter/qb sautera la séquence de l'interface utilisateur et retombera juste en exécutant l'entrée de la séquence d'exécution comme décrit dans votre réponse).

Source

2010-01-05 14:42:29

Les deux est vrai, il est dans CAPS et est répertorié dans SecureCustomProperties, et il est exécuté. Malheureusement FindRelatedProducts ne renvoie que la sortie du journal ci-dessus et ne trouve pas le produit précédemment installé: "MSI (s), il renvoie ceci: Sauter l'action FindRelatedProducts: déjà fait sur le côté client." Je ne peux que supposer que dans le cas de/qr, FindRelatedProducts est ignorée car elle existe dans la séquence d'interface utilisateur (même si elle n'est pas exécutée en raison de la séquence d'interface utilisateur réduite). En conséquence, il y a l'entrée en double. Cela pourrait être un comportement intentionnel, mais je ne peux pas dire si c'est le cas. – marco4net

Il n'y a donc pas de consignation précédente pour l'action FindRelatedProducts de la séquence d'interface utilisateur, seule celle de la séquence d'exécution est sauté? Ce n'est pas ce que j'aurais attendu du tout. Je vais devoir faire des tests plus tard. :) –

Oui, exactement, cela n'arrive qu'une fois en utilisant/qr et ensuite il s'exécute dans ExecuteSequence, merci pour votre soutien! Je ne sais pas si cela pourrait être prévu ou un bug dans ma version particulière de MSI/Windows Installer peut-être? – marco4net

Mise à jour des résultats d'installation à double entrée pour le logiciel installé (FindRelatedProducts pas exécutées)

Répondre

Questions connexes