Est-il acceptable pour planifier RemoveExistingProducts action personnalisée avant InstallValidate?

Question

Problème

J'ai un MSI qui crée et démarre un service Windows lors de l'installation et arrête et supprime le service pendant la désinstallation. Cela fonctionne très bien lors de l'installation et la désinstallation par lui-même, mais quand la mise à niveau, Fichiers utilisés dialogue est affiché (uniquement sur Vista et versions ultérieures en raison de la nouvelle Redémarrez le Gestionnaire ), ce qui indique que le service est en cours d'utilisation.

Arrière-plan

Fichiers utilisés dialogue est affiché pendant la séquence InstallExecute par InstallValidate action personnalisée, qui est prévue immédiatement avant la balise RemoveExistingProducts action personnalisée; cela signifie que la version précédente n'a pas encore été désinstallés, de sorte que le Fichiers utilisés dialogue devrait affichées.

La documentation MSDN indique que les RemoveExistingProducts l'action doit être prévue après la balise InstallValidate l'action, et j'ai actuellement RemoveExistingProducts les actions programmées immédiatement après InstallValidate action.

Solution potentiel

Je voudrais rééchelonner les RemoveExistingProducts action personnalisée immédiatement avant la balise InstallValidate action personnalisée de sorte que l'installation précédente a une chance d'arrêter et de supprimer le service avant la balise < strong> fichiers utilisés boîte de dialogue apparaît. J'ai essayé rééchelonnements les actions, et il semble fonctionner correctement sans effets secondaires indésirables (bien que le journal indique encore que le InstallValidate l'action exécute avant la balise RemoveExistingProducts action), mais Je hésite à utiliser cette solution car elle viole la documentation MSDN, et il peut y avoir des effets négatifs que je ne suis pas voyant encore.

Quelqu'un at-il essayé? La seule autre solution que je peux penser est d'avoir la nouvelle installation arrête le service de l'ancienne installation, mais ceci est indésirable car il nécessite l'installation d'avoir des informations sur toutes les anciennes installations qu'il peut mettre à niveau (arrêt de ce service particulier peut impliquer plus qu'un simple appel au gestionnaire de services pour l'arrêter).

Answer 1

Je mis en œuvre la solution potentielle décrite dans la question, la planification RemoveExistingProducts immédiatement avant InstallValidate . Je ne l'ai pas encore vu aucun problème, mais je signalerai encore une fois l'installation obtient une utilisation plus.

Mise à jour

Notre installation utilise depuis un certain temps, et je n'ai pas remarqué des effets néfastes.

Answer 2

Son déjà été construit pour MSI / Windows Installer ... le seul problème est que les classes d'installation de .NET ne pas utiliser la « Installation du service » MSI fonctionnalités. Ce qui se passe en réalité est que le MSI tente d'installer des fichiers et exécuter une commande personnalisée en utilisant les fichiers copiés (tout ce qui est tout Visual Studio met en MSI).

Pour le résoudre, vous pouvez modifier le MSI avec ORCA et ajoutez la ligne suivante à la ServiceControl tableau:

1   ServiceName 170     1   C__489628C5CC1144CB47F43E8BE7F3F31D

L'ID Component vous pouvez rechercher à partir de la table FILES ... Je viens choisi Component ID du principal fichier EXE. Le 170 est un bitmap qui indique Windows Installer pour arrêter et supprimer le service lors de l'installation et la désinstallation.

Cela effacera la route pour les installateurs .NET pour ajouter le service et vous pouvez utiliser le ServiceController pour démarrer le service après qu'il a été installé via la commande personnalisée.

Answer 3

Un problème potentiel serait que si l'utilisateur annule pendant InstallValidate (par exemple en raison de pas assez d'espace disque ou un fichier en cours d'utilisation) ou lors de l'installation, ce qui est le comportement de baisse de prix. La situation idéale est que l'état d'application est la même que celle qu'elle était avant (par exemple l'application précédente est installée). Vous pourriez être donner que avec votre séquençage, bien que rollback peut être une fonctionnalité que vous pouvez vivre sans.

Answer 4

Je pense que celui-ci vous aidera sans violer la documentation MSDN et d'éviter tout problème futur. Mettez une condition « installé ou PREVIOUSVERSIONSINSTALLED » et vous serez bien sur la mise à niveau aussi, car la propriété PREVIOUSVERSIONSINSTALLED est définie avant l'action InstallValidate pendant FindRelatedProducts. Je ne sais pas pourquoi, mais la propriété PREVIOUSVERSIONSINSTALLED est pas documentée dans MSDN, mais il existe et très utile, pour moi bien.