Démarrage des services qui dépendent des assemblages côte à côte à l'aide de Windows Installer

Question

Nous sommes en train de mettre à jour la construction du package .msi de notre produit pour Windows Server 2008. Le composant principal de notre installation est une application exécutée en tant que un service Windows. Une application de configuration est également exécutée pendant l'installation pour configurer les entrées de registre à utiliser par le service. Le service et l'application de configuration s'appuient sur le moteur d'exécution et le MFC Microsoft C/C++, qui sont inclus dans le fichier .msi en tant que modules de fusion. Les assemblys pour le runtime C/C++ et le MFC sont validés lors de la InstallFinalize, ce qui semble empêcher le démarrage du service en utilisant les mécanismes fournis par Windows Installer (est-ce correct?) Certainement, nous voyons des erreurs côte à côte avec moins l'application de configuration si elle est exécutée avant InstallFinalize.

L'approche que nous avons prise consiste à exécuter l'application de configuration en tant qu'action personnalisée "commit" après InstallFinalize, et que cette application démarre le service. Cela nécessite que l'application soit exécutée avec des privilèges élevés (pour lesquels nous utilisons un manifeste contenant une section trustInfo). Cela nécessite également que le fichier .msi soit configuré pour exécuter cette application sans Usurpation d'identité (qui autrement perturberait l'élévation de privilèges).

Est-ce une approche acceptable? À quel point ce futur sera-t-il prévisible? Y a-t-il des pièges à prendre en compte?

Il semble que ce soit un problème qui a été rencontré par d'autres:

http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12666.html

Y at-il un officiellement (ou officieusement) accepté façon de traiter ces problèmes?

En tant qu'addendum, existe-t-il un moyen de s'assurer qu'une application exécutée en tant qu'action personnalisée pendant le processus d'installation obtient le focus au démarrage? Les applications démarrées de cette manière semblent toujours apparaître derrière l'installateur et l'installateur reste concentré, ce qui n'est pas un effet particulièrement convivial. Merci beaucoup,

Answer 1

1. Vous pouvez compiler votre utilisation statique du MFC & C-Runtime de cette façon, vous ne serez pas averti.
2. Vous pouvez ajouter une interface utilisateur à la configuration, cela servira de programme de configuration, vous n'aurez donc pas besoin d'exécuter le programme de configuration pendant l'installation (ce qui n'est pas une bonne idée)
3. Vous pouvez installer le service en mode désactivé et exécutez la configuration une fois l'installation terminée. La configuration sera responsable de l'activation du service.

Answer 2

Voici une solution que j'ai utilisée pour ce genre de problème lors du ré-emballage de logiciels avec Windows Installer: un lanceur "bootstrap". En bref, au lieu d'utiliser les modules de fusion pour l'exécution (qui tous nous engager en même temps que tous les autres fichiers installés), vous pouvez faire une des opérations suivantes:

1. Fournir redistribuable MSIs pour la runtime/MFC, et les lancer d'abord par votre programme d'amorçage setup.exe. Le MSI de votre programme doit bien sûr tester que la version dont vous avez besoin est installée et peut-être même tester pour vous assurer que vous l'exécutez à partir de votre setup.exe. (Cette méthode a été popularisée par InstallShield, car ils aiment faire la fin de Windows Installer.Mieux encore, vous pouvez empaqueter votre MSI en tant que package parent qui installe deux MSI intégrés (ou plus): installez d'abord les runtimes requises, puis installez votre logiciel dans un fichier MSI enfant. Votre paquet parent confirmera que le MSI de l'exécution a bien été installé avant de continuer à installer votre MSI (qui a la liberté de démarrer les services puisque les prérequis sont déjà présents).

Il existe d'autres méthodes rustiques, comme votre action personnalisée de validation anticipée, mais elles ne sont pas aussi fiables que celles que je viens de mentionner.

Espérons que cela a du sens! J'avais l'habitude de vivre et respirer MSI, mais pas tellement plus de nos jours ...