continuous integration - хедер - WiX 3.0 выдает ошибку 217, а выполняется непрерывной интеграцией




раздел head wix (8)

imagi абсолютно прав! Я не мог поверить, что это истинный ответ. Недостаточная проверка и создание администратора TFS не являются хорошими решениями. Кроме того, я не мог найти NT \ Authority, чтобы добавить его в группу «Администраторы» и полностью застрял в этом.

Я получил ту же ошибку в Windows Server 2012 Datacenter как агент сборки. Решить проблему :

  1. Элемент списка
  2. Перейдите к переменным среды на машине агента сборки
  3. Создание двух системных переменных
  4. "PF86" который равен "C:\Program Files (x86)"
  5. "PF" который равен "C:\Program Files"
  6. Они настолько коротки, что я хочу сохранить символы. Я сделал их без окончательной обратной косой черты, потому что TEMP, TMP и другие были сделаны так, и я решил придерживаться стандарта MS для этих переменных.
  7. Измените переменную PATH, заменив каждый "C:\Program Files (x86)" на %PF86% и каждый "C:\Program Files" с %PF%
  8. Закройте и постройте и наслаждайтесь!
  9. Это сработало для меня. :)

Это ошибка, вызванная нашим автоматизированным комплектом сборки в Windows 2008 при работе с ICEs (после перехода с WiX 2.0 на WiX 3.0):

LGHT0217: Ошибка выполнения действия ICE 'ICE01'. Наиболее распространенной причиной такого отказа ICE является неправильно зарегистрированный механизм сценариев. Подробнее см. http://wix.sourceforge.net/faq.html#Error217 и как решить эту проблему. Внешний регистратор сообщений UI не ожидал следующего строкового формата: «Не удалось получить доступ к службе установщика Windows. Это может произойти, если установщик Windows установлен неправильно. Обратитесь за помощью к вашему персоналу поддержки». в light.exe (0, 0)

Кроме того, это ошибки, которые появляются в журнале событий:

MSIInstaller: Не удалось подключиться к серверу. Ошибка: 0x80070005 Продукт: [ProductName] - Ошибка 1719. Не удалось получить доступ к службе установщика Windows. Это может произойти, если установщик Windows установлен неправильно. Обратитесь за помощью в службу поддержки.

Наглядно:

  • VBScript и JScript были зарегистрированы под управлением администратора.
  • У службы интеграции есть разрешения для взаимодействия с рабочим столом и все файлы
  • Создает успех, когда выполняется вручную на одной машине другим пользователем или даже пользователем, зарегистрированным в качестве учетной записи интеграции (через RDP )

Пока у меня нет идей.

Как решить эту проблему при сохранении ICE-проверки?


Добавление учетной записи контроллера сборки TFS в локальную группу администраторов и перезапуск службы Windows сделали эту работу для меня.


Ни одно из вышеперечисленных предложений не работало для меня, для меня появился антивирус (mcafee) и, похоже, он обновил запись реестра vbscript.dll до неправильного местоположения DLL. Вот о чем нужно помнить:

  1. Некоторые из валидаций WiX ICE реализованы с использованием VBSCRIPT.
  2. Поэтому при компиляции MSI серверу сборки понадобится доступ к c: \ windows \ system32 \ vbscript.dll.
  3. Скорее всего, так или иначе пользователь, который запускает вашу сборку, потерял доступ к этой DLL.
  4. Как упомянуто в приведенных выше ответах, найдите доступ к доступу администратора / реестра и убедитесь, что у него есть его.

Вот шаги, которые я предпринял для устранения проблемы:

  1. Откройте cmd (запустите как admin) на машине агента сборки.
  2. Запустить RegEdit
  3. Выберите корень, затем нажмите ctrl + f и найдите следующую запись в реестре: {B54F3741-5B07-11cf-A4B0-00AA004A55E8}
  4. Найдите ключ InprocServer32 \ Default

  1. В моем агенте сборки путь был заменен местоположением DLL mcafee. Я обновил путь до c: \ windows \ system32 \ vbscript.dll
  2. Редактирование записи реестра было непростым, так как это была защищенная запись в реестре. Я использовал приведенную ниже ссылку, чтобы получить права доступа, измененные до того, как я смог отредактировать свойство: Изменить защищенную запись реестра

Как только я обновил путь, все начало работать как обычно.


Перейдите на свою машину сборки и перезапустите службу установщика Windows.


У меня есть некоторые предложения.

  • Попробуйте обновить версию установщика Microsoft на сервере сборки.
  • Убедитесь, что вы используете новейшую версию WiX 3.0, так как теперь она 3.0 стабилизирована.
  • Если все остальное не удается, попробуйте запустить службу сборки под определенным пользователем сборки, с которой вы можете играть с разрешениями для ...

Я нашел причину. Я попробовал все, что нашел, в том числе настраиваемое расширение валидатора, подобное тому, которое было опубликовано в Re: [WiX-users] light.exe случайно сбой при запуске ICE. ,

Это не проблема параллелизма, как предлагается в разных потоках. Это вызвано слишком большим блоком рабочей среды (PEB).

Оказывается, установщик Windows не может обрабатывать блок среды процесса размером более 32 кБ. В моей среде из-за количества переменных, заданных системой сборки и их размерами (например, переменной PATH, содержащей несколько дублированных значений), PEB составлял около 34 кБ.

Интересно, что для переменных среды , Windows XP и 2003 был жесткий предел PEB, равный 32 килобайтам. Вероятно, это приведет к простому сбою в сборе на предыдущем этапе сборки. Новейшая Windows 'не имеет такого ограничения, но я думаю, что разработчики Windows Installer ограничили свои внутренние буферы среды до 32 кбайт и изящно потерпели неудачу, когда превышено значение.

Проблема может быть легко воспроизведена:

  • Создайте файл .bat, который устанавливает переменные среды, размер которых превышает 32 кБ. Например, это может быть 32 строки set Variable<number>=<text longer than 1024 characters>
  • Запустить cmd.exe
  • Выполните созданный командный файл
  • Из того же окна cmd.exe:
    • Попробуйте создать пакет MSI с помощью WiX с проверкой ICE на OR
    • Запустите smoke.exe чтобы проверить ваш пакет ИЛИ
    • Просто запустите msiexec /i Package.msi
  • Все вышеприведенные команды будут сообщать об Error 1719 - Windows Installer could not be accessed .

Итак, решение - просмотрите сценарии сборки и уменьшите количество и размер переменных среды, чтобы они все вписывались в 32 кБ. Вы можете легко проверить результаты, выполнив:

set > environment.txt

Цель состоит в том, чтобы получить файл environment.txt меньше ~ 30 кБ.


Я столкнулся с той же проблемой и не хотел подавлять проверку ICE. Моя настройка: я использовал свой собственный компьютер в качестве агента сборки в Visual Studio Online (VSO). Мое решение состояло в том, чтобы изменить учетную запись, используемую для запуска службы на моей машине. Вместо того, чтобы использовать сетевую службу или локальную службу, я просто включил службу в свою учетную запись, которая обладала всеми необходимыми правами.


Конец истории :

После возиться с разрешениями учетной записи интеграции, DCOM , активацией службы и т. Д., Без всякой удачи, я, наконец, просто отключил проверку ICE в сборке непрерывной интеграции, сохраняя при этом локальную сборку.

Чтобы отключить проверку ICE, вы можете установить SuppressValidation в true в файле .wixproj:

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

Или передайте -sval командной строки light.exe в light.exe .