WiX 3.0 génère une erreur 217, tout en étant exécuté par continuous integration

C’est l’erreur qui est lancée par notre suite de build automatisée sous Windows 2008, lors de l’exécution d’ ICE (après la migration de WiX 2.0 vers WiX 3.0):

LGHT0217: Erreur lors de l’exécution de l’action ICE01 ‘ICE01’. La cause la plus fréquente de ce type de panne ICE est un moteur de script incorrectement enregistré. Voir http://wix.sourceforge.net/faq.html#Error217 pour plus de détails et pour résoudre ce problème. Le journal de messages de l’interface utilisateur externe n’attendait pas le format de chaîne suivant: «Impossible d’accéder au service Windows Installer. Cela peut se produire si Windows Installer n’est pas correctement installé. Contactez votre service d’assistance pour obtenir de l’aide. dans light.exe (0, 0)

En outre, ce sont les erreurs qui apparaissent dans le journal des événements:

MSIInstaller: Impossible de se connecter au serveur. Erreur: 0x80070005 Produit: [ProductName] – Erreur 1719. Impossible d’accéder au service Windows Installer. Cela peut se produire si Windows Installer n’est pas correctement installé. Contactez votre personnel d’assistance pour obtenir de l’aide.

Intuitivement:

  • VBScript et JScript ont été enregistrés sous admin.
  • Le service d’intégration a des permissions pour l’interaction du bureau et tous les fichiers
  • Les générations réussissent lorsqu’elles sont exécutées manuellement sur le même ordinateur par un autre utilisateur ou même par un utilisateur connecté en tant que compte d’intégration (via RDP )

Je suis à court d’idées jusqu’à présent.

Comment résoudre ce problème tout en conservant la validation ICE?

Fin de l’histoire :

Après avoir bidouillé les permissions du compte d’intégration, de DCOM , de l’activation du service, etc. sans aucune chance, j’ai finalement simplement désactivé la validation ICE dans la construction d’continuous integration, tout en la conservant dans la version locale.

Pour désactiver la validation ICE, vous pouvez définir SuppressValidation sur true dans le fichier .wixproj:

 true  

Ou transmettez l’option de ligne de commande light.exe à light.exe .

L’ajout du compte du contrôleur de compilation TFS au groupe d’administration local et le redémarrage du service Windows ont fait l’affaire pour moi.

J’ai trouvé la cause profonde. J’ai essayé tout ce que j’ai trouvé, y compris une extension de validateur personnalisée similaire à celle publiée dans Re: [WiX-users] light.exe a échoué de manière aléatoire lors de l’exécution d’ICE. .

Ce n’est pas un problème de simultanéité comme suggéré dans divers threads. Il est causé par un PEB (Process Environment Block) trop important.

Il s’avère que Windows Installer ne peut pas gérer un bloc d’environnement de processus supérieur à 32 Ko. Dans mon environnement, en raison du nombre de variables définies par le système de génération et de leur taille (par exemple, variable PATH contenant plusieurs valeurs dupliquées), le PEB était d’environ 34 Ko.

Fait intéressant, selon les variables d’environnement , Windows XP et 2003 avaient une limite ssortingcte de PEB définie à 32 kilo-octets. Cela provoquerait probablement une rupture de build facile à prendre en main dans une phase antérieure de la construction. Windows plus récent ne possède pas une telle limite, mais je suppose que les développeurs de Windows Installer ont limité leurs tampons d’environnement interne à 32 Ko et échoué normalement lorsque la valeur est dépassée.

Le problème peut être facilement reproduit:

  • Créez un fichier .bat qui définit les variables d’environnement dont la taille dépasse 32 Ko. Par exemple, il peut s’agir de 32 lignes de set Variable=
  • Lancer cmd.exe
  • Exécutez le fichier de commandes que vous avez créé
  • De la même fenêtre cmd.exe:
    • Essayez de construire le package MSI en utilisant WiX avec la validation ICE sur OR
    • Exécutez smoke.exe pour valider votre package OU
    • Il suffit de lancer msiexec /i Package.msi
  • Toutes les commandes ci-dessus finiront par signaler l’ Error 1719 - Windows Installer could not be accessed .

La solution consiste donc à examiner vos scripts de génération et à réduire le nombre et la taille des variables d’environnement afin qu’ils puissent tous être intégrés à 32 Ko. Vous pouvez facilement vérifier les résultats en exécutant:

 set > environment.txt 

L’objective est d’obtenir un fichier environment.txt inférieur à ~ 30 Ko.

La description correcte (sans solution, sauf si l’ajout du compte CruiseControl dans le groupe des administrateurs locaux peut passer comme solution):

Citation de Wix 3.5 & Cruise Control donne errorLGHT0217 :

La validation ICE nécessite un compte interactif ou des privilèges d’administrateur pour être heureux. Voir, par exemple, les projets WiX vs TFS 2010 Team Build (2009-11-14) ou Re: [WiX-users] Aide sur le patch de construction (2009-11-20).

imagi a totalement raison! Je ne pouvais pas croire que c’était la vraie réponse. Supprimer la validation et faire de l’administrateur utilisateur de TFS ne sont pas de bonnes solutions. De plus, je n’arrivais pas à trouver NT \ Authority pour l’append au groupe Administrateurs et j’étais totalement bloqué dans cette tâche.

J’ai reçu la même erreur sur Windows Server 2012 Datacenter en tant qu’agent de génération. Résoudre le problème :

  1. Élément de la liste
  2. Accéder aux variables d’environnement sur la machine de l’agent de génération
  3. Créer deux variables système
  4. "PF86" qui est égal à "C:\Program Files (x86)"
  5. "PF" qui est égal à "C:\Program Files"
  6. Ils sont si courts parce que je veux sauvegarder des caractères. Je les ai faits sans la barre oblique inverse finale parce que TEMP, TMP et d’autres ont été faits ainsi et j’ai décidé de m’en tenir au standard de MS pour ces variables.
  7. Modifiez la variable PATH en remplaçant tous les "C:\Program Files (x86)" par %PF86% et tous les "C:\Program Files" par %PF%
  8. Fermez et construisez et appréciez!
  9. Cela a fonctionné pour moi. 🙂

Je recevais la même erreur ICE, mais le problème est devenu corrompu Windows Installer Service. Cette solution a fonctionné pour moi: http://support.microsoft.com/kb/315353

  1. Connectez-vous à votre ordinateur en tant qu’administrateur.
  2. Cliquez sur Démarrer, puis sur Exécuter.
  3. Dans la zone Ouvrir, tapez cmd, puis cliquez sur OK.
  4. À l’invite de commandes, tapez msiexec.exe / unregister, puis appuyez sur ENTRÉE.
  5. Tapez msiexec / regserver, puis appuyez sur ENTRÉE.
  6. Redémarrer Windows

En outre, vérifiez que le compte SYSTEM dispose des permissions d’access de contrôle total sur la hive HKEY_CLASSES_ROOT dans le registre Windows. Dans certains cas, vous devrez peut-être également append des comptes d’administrateur.

De http://wix.sourceforge.net/faq.html#Error217 :

Dans WiX v3, Light exécute automatiquement la validation – les évaluateurs de cohérence interne (ICE) de Windows Installer – après chaque génération réussie. La validation est un excellent moyen de détecter les erreurs de création courantes pouvant entraîner des problèmes de service, raison pour laquelle elle est désormais exécutée par défaut. Malheureusement, il existe un problème commun qui se produit sous Windows Vista et Windows Server 2008 et qui peut entraîner l’échec des ICE. Pour plus de détails sur la cause et les solutions, consultez le blog de Heath Stewart et WebLog d’Aaron Stebner .

J’ai des suggestions.

  • Essayez de mettre à jour la version de Microsoft Installer sur le serveur de génération
  • Assurez-vous que vous utilisez la dernière version de WiX 3.0, puisque sa version 3.0 est désormais stable.
  • Si tout le rest échoue, essayez d’exécuter le service de génération sous un utilisateur de build spécifique avec lequel vous pouvez manipuler des permissions pour …

J’ai fait face au même problème et n’a pas aimé supprimer la validation ICE. Ma configuration: J’ai utilisé mon propre ordinateur en tant qu’agent de génération sur Visual Studio Online (VSO). Ma solution consistait à modifier le compte utilisé pour exécuter le service sur ma machine. Au lieu d’utiliser le service réseau ou le service local, j’ai simplement ouvert le service avec mon propre compte, qui possédait tous les droits nécessaires.

Accédez à votre machine de génération et redémarrez le service Windows Installer

Aucune des suggestions ci-dessus n’a fonctionné pour moi, pour moi l’anti-virus (mcafee) est entré dans l’image et semble avoir mis à jour l’entrée de registre de vbscript.dll vers un mauvais emplacement de DLL. Ce sont les choses à garder à l’esprit:

  1. Certaines des validations WiX ICE sont implémentées à l’aide de VBSCRIPT.
  2. Ainsi, lors de la compilation du fichier MSI, le serveur de génération doit avoir access au fichier c: \ windows \ system32 \ vbscript.dll.
  3. Les chances sont que, d’une manière ou d’une autre, l’utilisateur qui exécute votre version ait perdu l’access à cette DLL.
  4. Comme mentionné dans les réponses ci-dessus, recherchez l’access administrateur / registre et assurez-vous que votre utilisateur l’a bien.

Voici les étapes que j’ai sockets pour résoudre le problème:

  1. Ouvrez cmd (exécuté en tant qu’administrateur) sur la machine de l’agent de génération.
  2. Exécuter RegEdit
  3. Sélectionnez la racine, puis cliquez sur ctrl + f et recherchez l’entrée de registre suivante: {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
  4. Recherchez la clé InprocServer32 \ Default

entrer la description de l'image ici

  1. Sur mon agent de génération, le chemin d’access a été remplacé par un emplacement DLL mcafee. J’ai mis à jour le chemin d’access à c: \ windows \ system32 \ vbscript.dll
  2. La modification de l’entrée de registre n’était pas facile car il s’agissait d’une entrée de registre protégée. J’ai utilisé le lien ci-dessous pour obtenir des permissions d’access modifiées avant de pouvoir modifier la propriété: Modifier l’entrée de registre protégée

Une fois le chemin mis à jour, tout a fonctionné comme d’habitude.