WiX 3.0 lance l'erreur 217, alors qu'il est exécuté par l'intégration continue

Question

Voici l'erreur qui est générée par notre suite de construction automatisée sur Windows 2008, lors de l'exécution du programme CIE (après avoir migré de WiX 2.0 à WiX 3.0) :

LGHT0217 : Erreur dans l'exécution de l'action ICE 'ICE01'. La cause la plus fréquente de ce type d'échec de l'ICE est un moteur de script mal enregistré. Voir http://wix.sourceforge.net/faq.html#Error217 pour plus de détails et pour savoir comment résoudre ce problème. Le format de chaîne suivant n'a pas été pris en compte par l'enregistreur de messages de l'interface utilisateur externe : "Il n'a pas été possible d'accéder au service Windows Installer. Ce problème peut survenir si le programme d'installation de Windows n'est pas correctement installé. Contactez votre personnel 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 : Échec de la connexion au serveur. Erreur : 0x80070005 Produit : [Nom du produit] -- Erreur 1719. Il n'a pas été possible d'accéder au service Windows Installer. Cette erreur peut se produire si le programme d'installation de Windows n'est pas correctement installé. Contactez votre personnel d'assistance pour obtenir de l'aide.

Intuitivement :

• VBScript et JScript ont été enregistrés sous l'administration.
• Le service d'intégration dispose d'autorisations pour l'interaction avec le bureau et tous les fichiers.
• Les constructions réussissent lorsqu'elles sont exécutées manuellement sur la même machine 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 pour l'instant.

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

Answer 1

Fin de l'histoire :

Après avoir modifié les autorisations du compte d'intégration, DCOM Sans succès, j'ai finalement désactivé la validation ICE dans la version d'intégration continue, tout en la conservant dans la version locale.

Pour désactiver la validation ICE, vous pouvez attribuer la valeur true à SuppressValidation dans le fichier .wixproj :

    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>

Ou passer le -sval L'option de ligne de commande light.exe .

Answer 2

L'ajout du compte du contrôleur de construction TFS au groupe d'administrateurs locaux et le redémarrage du service Windows ont permis de résoudre le problème.

Answer 3

J'ai trouvé la cause première. J'ai essayé tout ce que j'ai trouvé, y compris une extension de validateur personnalisée similaire à celle postée dans Re : [WiX-users] light.exe échoue aléatoirement lors de l'exécution des ICEs. .

Il ne s'agit pas d'un problème de concurrence comme cela a été suggéré dans plusieurs fils de discussion. Il est dû à un bloc d'environnement de processus (PEB) trop grand.

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

Il est intéressant de noter que le taux d'utilisation de l'eau par les femmes est plus élevé que celui des hommes. Variables d'environnement Windows XP et 2003 avaient une limite stricte de PEB fixée à 32 kilo-octets. Cela aurait probablement causé une rupture de construction facile à rattraper dans une phase antérieure de la construction. Les versions plus récentes de Windows n'ont pas cette limite, mais je suppose que les développeurs de Windows Installer ont limité leurs tampons d'environnement internes à 32 kB et qu'ils échouent gracieusement 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 kB. Par exemple, il peut s'agir de 32 lignes de set Variable<number>=<text longer than 1024 characters>
• Lancer cmd.exe
• Exécutez le fichier batch que vous avez créé
• A partir de la même fenêtre cmd.exe :
  • Essayez de construire le paquet MSI en utilisant WiX avec la validation ICE activée OU
  • Exécuter smoke.exe pour valider votre colis OU
  • Il suffit de courir msiexec /i Package.msi
• Toutes les commandes ci-dessus aboutiront à l'établissement d'un rapport Error 1719 - Windows Installer could not be accessed .

La solution est donc de revoir vos scripts de construction et de réduire le nombre et la taille des variables d'environnement pour qu'elles tiennent toutes dans 32 kB. Vous pouvez facilement vérifier les résultats en exécutant :

set > environment.txt

L'objectif est d'obtenir un dossier environment.txt inférieures à ~30 kB.

Answer 4

La description correcte (sans solution, sauf si l'ajout du compte CruiseControl dans le groupe des administrateurs locaux peut passer pour une solution) du problème :

Citation de Wix 3.5 & Le régulateur de vitesse donne l'erreurLGHT0217 :

La validation ICE nécessite un compte interactif ou des privilèges d'administrateur pour être effectuée. heureux. Voir par exemple WiX Projects vs. TFS 2010 Team Build (2009-11-14) ou Re : [WiX-users] Aide à la construction du patch (2009-11-20).

Answer 5

Imagi a tout à fait raison ! Je n'arrive pas à croire que c'est la vraie réponse. Supprimer la validation et faire de l'utilisateur TFS un administrateur ne sont pas de bonnes solutions. De plus, je n'ai pas pu trouver NT \Authority pour l'ajouter au groupe des administrateurs et j'étais totalement bloqué dans cette situation.

J'ai obtenu la même erreur sur Windows Server 2012 Datacenter comme Build Agent. Pour résoudre le problème :

1. Élément de la liste
2. Aller dans Variables d'environnement sur la machine de l'agent de construction
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. Je les ai faites sans la barre oblique inverse finale parce que TEMP, TMP et d'autres ont été faites ainsi et j'ai décidé de m'en tenir à la norme MS pour ces variables.
7. Modifier la variable PATH en remplaçant chaque "C:\Program Files (x86)" avec %PF86% et chaque "C:\Program Files" avec %PF%
8. Fermez, construisez et profitez !
9. Cela a fonctionné pour moi :)

MISE À JOUR J'ai trouvé une meilleure solution : Éditeur d'environnement rapide fera tout cela et bien plus encore pour vous. Automatiquement.