WiX 3.0 déclenche une erreur 217, tout en étant exécuté par l'intégration continue

C'est l'erreur qui est générée par notre système automatisé suite sur Windows 2008, lors de l'exécution de ICEs (après la migration de WiX 2.0 pour WiX 3.0):

LGHT0217: Erreur lors de l'exécution de la GLACE de l'action "ICE01'. La cause la plus fréquente de ce type de GLACE de l'échec est un incorrectement enregistré le moteur de script. Voir http://wix.sourceforge.net/faq.html#Error217 pour plus de détails et comment résoudre ce problème. La chaîne de caractères de format n'était pas prévu par l'externe de l'INTERFACE utilisateur enregistreur de message: "Le Service Windows Installer n'a pas pu être consulté. Cela peut se produire si le programme d'installation de Windows n'est pas installé correctement. Contactez votre support technique pour assistance.". dans light.exe(0, 0)

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

MSIInstaller: impossible de se connecter au serveur. Erreur: 0 x 80070005
Produit: [ProductName] -- Erreur 1719. Le Service Windows Installer n'a pas pu être consulté. Cela peut se produire si le programme d'installation de Windows n'est pas installé correctement. Contactez votre support technique pour assistance.

Intuitivement:

VBScript et JScript ont été enregistrés en vertu de l'admin.
Service de l'intégration a les autorisations pour l'interaction avec le bureau et tous les fichiers
Construit réussir, lorsqu'il est exécuté manuellement sur la même machine par un autre utilisateur ou même de l'utilisateur connecté en tant qu'intégration de compte (via RDP)

Je suis d'idées si loin.

Comment puis-je résoudre ce problème tout en gardant la GLACE de validation?

Grande que la FAQ url dans la errormessage est cassé...

InformationsquelleAutor Rinat Abdullin | 2009-06-30

48

Fin de l'histoire:

Après jongler avec les autorisations de l'intégration de compte, DCOM, l'activation du service, etc. sans un peu de chance, j'ai finalement simplement désactivé la GLACE de validation dans la version d'intégration continue, tout en restant dans la construction locale.

Pour désactiver la GLACE de validation vous pouvez définir SuppressValidation à vrai dans l' .wixproj fichier:
```
    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>
```
Ou passer la -sval option de ligne de commande pour light.exe.
- C'était la meilleure réponse que je pouvais venir avec, trop. Il semble que le compte de laquelle le processus de construction s'exécute sous doit élever afin de se connecter au Service Windows Installer pour exécuter le Ciem. J'ai pensé à donner le processus de construction des autorisations d'administrateur pour résoudre le problème, mais pensé juste de le désactiver sur le CI de construire est tout autant un problème pour l'instant.
- Comment avez-vous désactivez la GLACE de validation?
- voir les ajouts dans la réponse
- Ce n'est pas vraiment une réponse, mais plutôt une, pas très bon, la solution de contournement.
- Peut-être que ce n'est pas une bonne solution, mais c'est la seule façon que j'ai trouvée pour générer mon MSI. Merci donc de Rinat !
- Pour les autres, de considérer cette réponse comme une solution viable, vous devez comprendre que la violation de la GLACE peut vous apporter des ennuis en essayant de respecter f.ex msdn.microsoft.com/en-us/library/windows/desktop/... ainsi Que de la production sur site formalisé des contrôles. En bref. Ne permettent pas de résoudre votre problème en désactivant la GLACE contrôles.
- Pas besoin de le supprimer de validation. Vérifier ma réponse 3 postes.
- Ni de jouer avec l'environnement, ni de donner mon agent de build utilisateur des privilèges d'administrateur a fonctionné pour moi. Les deux WiX Toolset question 3968 et un post par Rob Mensching sur WiX-Utilisateurs dire que la seule solution fiable est de désactiver la GLACE. Quelque chose comme WiX du brise-GLACE de projet pourrait arranger les choses un jour.
InformationsquelleAutor Rinat Abdullin
30

Ajoutant le build TFS compte de contrôleur de groupe admin local et de redémarrer le service windows a fait le travail pour moi.
- Mais c'est face à l'Équipe d'établir les meilleures pratiques, voir: msdn.microsoft.com/en-us/library/dd578625
- Je suis d'accord que c'est une mauvaise pratique, et pas quelque chose que j'aime faire, mais c'est le moindre de deux maux. La désactivation de la GLACE de validation complètement de votre Msi par rapport à prendre l'accumulation du compte administrateur.
- Pour continuer à réfléchir sur @Jeff s commentaire, c'est vraiment un choix évident: utiliser le temps sur la qualité de la sécurisation d'une machine de compilation en toute sécurité sur le ontranet, ou de désactiver une case à qui, potentiellement, des pauses, des trucs comme "conçu pour windows server" logo de la vérification.
- Il serait bien de comprendre ce exact des autorisations sont requises au lieu de donner la pleine rôle admin...
- Dans mon entreprise, il n'est pas autorisé à le faire. Ivan a commenté ci-dessus, quelqu'un sait quelle exacte des autorisations sont nécessaires? (BTW, nous avons essayé cette solution proposée temporairement et cela a fonctionné)
InformationsquelleAutor Casper Leon Nielsen
23

J'ai trouvé la cause. J'ai essayé tout ce que j'ai trouvé, y compris validateur personnalisé extension similaire à un posté dans Re: [WiX-users] light.exe a échoué de façon aléatoire lors de l'exécution de l'ICEs..

Ce n'est pas un problème de concurrence comme suggéré dans plusieurs threads. Elle est causée par un trop grand nombre de Processus de Bloc d'Environnement (PEB).

Il s'avère que le programme d'installation de Windows ne peut pas gérer un environnement de processus de bloc de plus de 32 ko. Dans mon environnement, en raison du nombre de variables définies par le système de compilation et de leur taille (par exemple, Variable de CHEMIN d'accès contenant plusieurs valeurs dupliquées), PEB était d'environ 34 ko.

Il est intéressant de noter, par Les Variables D'Environnement, Windows XP et 2003, ont eu une dure limite de PEB de 32 kilo-octets. Ce serait sans doute provoquer un facile à attraper construire pause dans une phase antérieure de la construction. Plus récente de Windows n'a pas de limite, mais je suppose que le programme d'installation de Windows développeurs limitée de leur environnement interne tampons à 32 ko et ne parviennent pas normalement lorsque la valeur est dépassée.

Le problème peut être facilement reproduit:
- Créer un .fichier bat qui définit les variables d'environnement, dont la taille dépasse 32 ko. Par exemple, il peut être de 32 lignes de set Variable<number>=<text longer than 1024 characters>
- Lancement cmd.exe
- Exécuter le fichier de commandes que vous avez créé
- À partir de la même cmd.exe fenêtre:
  - Essayez de construire le package MSI à l'aide de WiX avec de la GLACE pour la validation OU
  - Exécuter smoke.exe pour valider votre colis OU
  - Simplement exécuter msiexec /i Package.msi
- Toutes les commandes ci-dessus sera à la fin des rapports Error 1719 - Windows Installer could not be accessed.
Donc, la solution est - réviser vos scripts de construction et de réduire le nombre et la taille des variables d'environnement afin qu'ils appartiennent tous à 32 ko. Vous pouvez facilement vérifier les résultats en cours d'exécution:
```
set > environment.txt
```
L'objectif est d'obtenir un fichier environment.txt plus petit que ~30 ko.
- Cela semble être la question, j'ai été frapper ainsi. J'ai été me douter de la simultanéité, mais il n'y avait pas assez de Msi construction en parallèle. Merci beaucoup pour le partage de cette solution. Aimerais savoir comment vous avez enfin débogué il.
- Je suppose que vous dire que c'est l'une des causes du problème, parce que mes variables d'environnement sont à moins de 2K.
- A fonctionné pour moi aussi, merci. Mais mon seuil de tolérance est bas. 6KB (-> 5900 caractères) travaillé. 10 KO (-> 9300 caractères) montre l'erreur. En cours d'exécution sur Windows Server 2016 au sein de l'électron-builder 20.39.0
InformationsquelleAutor imagi
9

La description correcte (sans trouver de solution, sauf si l'ajout de la CruiseControl compte dans le groupe administrateurs local peut passer en tant que solution) du problème:

Citation de Wix 3.5 & régulateur de vitesse donne errorLGHT0217:

GLACE besoins en matière de validation d'un compte interactif ou des privilèges d'administrateur pour
heureux. Voir, par exemple, WiX Projets vs Team Build TFS 2010 (2009-11-14) ou Re: [WiX-utilisateurs] Aider à la construction de patch (2009-11-20).

InformationsquelleAutor vlad2135
4

imagi est totalement raison! Je ne pouvais pas croire que c'est la vraie réponse. Supressing de validation et de prise de TFS utilisateur de l'Administrateur ne sont pas de bonnes solutions. En Plus je ne pouvais pas trouver NT\Autorité pour l'ajouter au groupe Administrateurs et a été totalement coincé dans cette.

J'ai eu le même message d'erreur sur Windows Server 2012 Datacenter Agent de Build.
Pour résoudre le problème :
1. Élément de la liste
2. Aller à des Variables d'Environnement sur l'agent de build machine
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 court parce que je veux enregistrer caractères.Je les ai faites sans la dernière barre oblique inverse car TEMP, TMP et d'autres ont été faites et j'ai décidé de coller à MS standard pour ces variables.
7. Modifier la variable PATH en remplaçant chaque "C:\Program Files (x86)" avec %PF86% et tous les "C:\Program Files" avec %PF%
8. Proximité et de construire et profitez-en!
9. Il a travaillé pour moi. 🙂
InformationsquelleAutor Ognyan Dimitrov
2

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

Dans WiX v3, la Lumière s'exécute automatiquement la validation--
Programme D'Installation De Windows Cohérence Interne Des Évaluateurs (Ice)
--après chaque succès de la construire. La Validation est un
excellent moyen pour attraper commun de création erreurs qui peuvent conduire à des problèmes de service,
c'est pourquoi il est aujourd'hui dirigée par défaut. Malheureusement, il y a un problème commun
qui se produit dans Windows Vista et Windows Server 2008 qui peuvent causer de l'ICEs à
un échec. Pour plus de détails sur la cause et comment résoudre le problème, voir
Heath Stewart Blog
et
Aaron Stebner WebLog.
- N'ont rien fait de en lien fait de vous aider à résoudre ce problème?
- Qui n'a pas fonctionné pour moi. J'ai un tout nouveau server 2008 R2 x64 et les dll sont inscrits sous HKLM pas HKCU.
InformationsquelleAutor gregmac
2

Je commençais à même la GLACE d'erreur, mais le problème s'est avéré être corrompu au Service Windows Installer.
Cette solution a fonctionné pour moi:
http://support.microsoft.com/kb/315353
1. Ouvrez une session sur 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 commande, tapez msiexec.exe /annuler l'enregistrement, puis appuyez sur ENTRÉE.
5. Tapez msiexec /regserver, puis appuyez sur ENTRÉE.
6. Redémarrer Windows
Vérifiez également que le SYSTÈME de compte a le plein contrôle des autorisations d'accès à la
HKEY_CLASSES_ROOT ruche dans le registre Windows. Dans certains cas, vous pouvez également ajouter des comptes d'Administrateur.

InformationsquelleAutor Vladimir Demirev
1

J'ai quelques suggestions.
- Essayez de mettre à jour le programme d'installation de Microsoft version sur le serveur de build
- Assurez-vous d'utiliser la version la plus récente de WiX 3.0, puisque c'est la version 3.0 stable maintenant.
- Si tout le reste échoue, essayez d'exécuter le service en vertu d'un build spécifique de l'utilisateur à qui vous pouvez jouer avec des autorisations pour...
- 1. Oui; 2. Plus tard; 3. Je peux modifier les autorisations de l'intégration de compte.
- Essayez d'ajouter de la construction de l'utilisateur à l'DCOM groupe d'utilisateurs locaux.
- N'ai pas le temps. J'ai fini par la désactivation de la GLACE de validation dans la version d'intégration.
InformationsquelleAutor Christopher Karper
1

J'ai connu le même problème et n'a pas à supprimer de la GLACE de validation. Ma configuration: j'ai utilisé mon propre ordinateur en tant qu'agent de build sur Visual Studio Online (VSO). Ma solution a été de changer le compte utilisé pour exécuter le service sur ma machine. Au lieu d'utiliser le Réseau de Service ou de Service Local, j'ai simplement fait le service connectez-vous avec mon propre compte, et qui avaient tous les droits nécessaires.
- C'est exactement ce qui se passait pour moi. Le compte sous lequel l'accumulation des services de l'exécution avait eu des problèmes d'autorisation. J'ai changé l'utilisateur et de le construire maintenant passe
InformationsquelleAutor nath
0

Aller à votre machine de compilation et de redémarrer le service Windows Installer

InformationsquelleAutor TVSuser1654136
0

Aucune des suggestions ci-dessus a fonctionné pour moi, pour moi l'anti-virus (mcafee) est entré dans l'image et dirait qu'il a mis à jour le vbscript.dll l'entrée de registre DLL tort emplacement. Ce sont les choses à garder à l'esprit:
1. Certains WiX GLACE validations sont mis en œuvre à l'aide de VBSCRIPT.
2. Donc lors de la compilation du MSI, le serveur de build auraient besoin d'un accès à la c:\windows\system32\vbscript.dll.
3. Les Chances sont que quelque part, l'utilisateur qui exécute votre construire perdu l'accès à cette DLL.
4. Comme mentionné dans les réponses ci-dessus ne regarde pour l'accès admin/registre d'accès et assurez-vous que votre utilisateur a elle.
Voici les étapes que j'ai pris pour résoudre le problème:
1. Ouvrir cmd (exécuter en tant qu'admin) sur l'agent de build de la machine.
2. Exécutez RegEdit
3. Sélectionnez la racine, puis cliquez sur ctrl + f et la Recherche de l'entrée de registre suivante : {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
4. Recherchez le InprocServer32\Clé par Défaut
1. Sur mon agent de build, le chemin a été remplacé par un mcafee DLL emplacement. J'ai mis à jour le chemin de retour à l'c:\windows\system32\vbscript.dll
2. Édition de l'entrée de registre n'a pas été facile, car il était un protégé de l'entrée de registre. J'ai utilisé le lien ci-dessous pour obtenir les autorisations d'accès changé avant que je puisse modifier la propriété: Edit protégés entrée de registre
Une fois que j'ai mis à jour le chemin d'accès, tout a commencé à travailler comme d'habitude.

InformationsquelleAutor Isaiah4110

Vous devez vous connecter pour publier un commentaire.