Не выбранная функция устанавливается

Я оказался на работе в DevOps, имея очень мало знаний об InstallShield или о том, что я делаю. Все, что я узнал, я узнал, прочитав документацию Flexera. Одна из наших заявок - это проблема, которую я не смог найти в результатах поиска в Google - я, вероятно, использую неправильные поисковые термины, но не знаю, какие из них правильные.

По сути, наш установщик имеет множество функций. Некоторые из этих функций имеют подфункции, которые всегда устанавливаются, если вы выбираете основную функцию. Все установлено для установки по умолчанию, но вы можете отключить любую из функций. Они должны быть полностью автономными, если вы хотите, чтобы они были. Подфункции компонента 1 видны в установщике (хотя вы не можете отменить их выбор или выбрать их отдельно от компонента 1), но функция 4 - нет.

|- FEATURE 1
|---- FEATURE A
|---- FEATURE B
|---- FEATURE C
|- FEATURE 2
|- FEATURE 3
|- FEATURE 4
|---- FEATURE D
|---- FEATURE E
|---- FEATURE F
| ...

Функция F имеет ровно один компонент. Этот компонент устанавливает целую кучу DLL-файлов и конфигурационных файлов - не лучшая практика, но и не то, что я могу изменить в рамках этой проблемы. При просмотре списка компонентов для этого компонента устанавливается только функция F. Он - и он содержит папку - не отображается при просмотре файлов для какой-либо другой функции.

Функция F устанавливается, когда вы выбираете функцию 1 в качестве единственной опции. Это может произойти и с другими функциями, но функция 1 является самой быстрой для установки, поэтому она была протестирована с наибольшим количеством.

Это базовый проект MSI. Я попытался заставить InstallShield создать журнал, установив для параметра "Создать журналы MSI" значение "Да", но он не генерировал файл журнала, когда я запускал тестовую установку, запустив Setup.exe. Я просмотрел сценарии в пользовательском интерфейсе и выполнил последовательность установки, и было похоже, что ничего не выбирало функцию F.

Я пропустил место, где функции могут быть связаны друг с другом - и если да, то где?

Источник

2 ответа

Решение

Попытка конкретного ответа:

Настраиваемые действия. Исходя из доступной информации (0 условий), я предполагаю, что одно или несколько настраиваемых действий используются для реализации логики функции, которую вы описали выше. Вы должны быть в состоянии найти код пользовательского действия в проекте Installscript view Я бы предположил? (со связанной записью настраиваемого действия в Custom actions view).

Также возможно, что Installscript не используется, но логика реализована на другом языке (VBScript, C++, JavaScript, PowerShell и т. д.) - в этом случае вам следует перейти непосредственно к Custom actions view вместо этого и искать подозреваемых. Источник может быть встроен в пользовательское действие (scrips) или сохранен в другом месте (всегда так для C++).

Ведение журнала. Чтобы включить ведение журнала, попробуйте открыть проект, а затем перейдите к Build => Settings... => MSI Log File Теперь нажмите All Error Messages а также Verbose Output и введите имя файла в Log File коробка. Нажмите OK, Теперь попробуйте собрать и запустить свой проект. Вот как включить ведение журнала с помощью msiexec.exe (за пределами Installshield). Конкретный пример; команда ведения журнала в ее простейшей форме:

msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log

ОБНОВЛЕНИЕ: Я нашел этот образец в KDB Installshield (Q208877) ( KDB). Он использует некоторые очень странные методы выбора плодов - подробности смотрите в самой статье. Есть загружаемый файл ISM. Немного лучший подход, на мой взгляд, здесь. Ваша установка может использовать некоторые из этих методов.

Попытка общего ответа:

Существует целый список механизмов, которые могут повлиять на выбор функции, и он показан ниже. Ниже в основном для проектов Basic MSI, для проектов Installscript MSI доступны еще больше механизмов - в основном функции Installscript. Перед списком несколько важных моментов:

  • Названия функций чувствительны к регистру!
  • Различный механизм ниже может определенно мешать друг другу.

А теперь список. Насколько мне известно, выбор функции может зависеть (как минимум) от следующих механизмов:

  1. стандарт msiexec.exe Командная строка
    • Пользователь может установить свойства параметров установки функции через msiexec.exe command line,
    • В общем-то ADDLOCAL а также REMOVE, но другие также могут быть использованы (см. ссылку выше).
    • Образец: msiexec.exe /i MySetup.msi ADDLOCAL="Core,English,German,SDK"
  2. GUI настройки взаимодействия с пользователем
    • Диалоговое окно выбора функции MSI GUI (если доступно в настройках).
    • Некоторые настройки (не все) имеют "Пользовательский" диалог, который позволяет пользователю выбирать, какие функции устанавливать, а какие нет.
    • Видимые функции могут быть непосредственно затронуты (и их подфункции - видимые или нет - в зависимости от конфигурации функции - поиск msidbFeatureAttributesFollowParent).
    • Есть несколько возможных состояний функций для установки в некоторых настройках. Рекламируйте функцию, установите функцию, не устанавливайте функцию и т.д.
    • Там могут быть настраиваемые действия, запускаемые из графического интерфейса настройки, которые влияют на состояние выбора функции (см. Раздел настраиваемых действий ниже).
      • Например, в зависимости от взаимодействия пользователя с выбором одной функции, другие функции могут быть выбраны или не выбраны.
      • Для установок MSI Installscript логика для этого встроена (и также настраивается). Для базовых настроек MSI можно сделать что-то подобное, но есть меньше автоматики.
  3. INSTALLLEVEL
    • Это обязательное свойство настройки должно быть упомянуто. Это базовая линия, определяющая, должна ли быть установлена ​​конкретная функция или нет. Каждая установка имеет INSTALLLEVEL,
    • Каждая функция имеет свой собственный атрибут уровня, и функция будет установлена, если ее атрибут уровня установлен равным или меньшим номером, чем общий параметр установки. INSTALLLEVEL,
    • Как следствие, можно повлиять на запрошенное состояние установки для нескольких функций, изменив настройки INSTALLLEVEL,
    • Плохая, но не редкая практика - это макс INSTALLLEVEL до 32767, чтобы принудительно установить все функции. Это неправильно, потому что некоторые функции могут быть несовместимы с системой (неправильные файлы для неправильной системы).
  4. Особые условия
    • Как уже упоминалось, все функции имеют атрибут уровня, которым можно манипулировать с помощью условных операторов, которые оцениваются во время выполнения.
    • Это связано с предыдущим пунктом, но наоборот: теперь мы меняем атрибут уровня каждого объекта, а не собственный базовый уровень объекта установки (INSTALLLEVEL).
    • Смотрите столбец уровня в Feature Table,
    • Фактическая условная логика находится в Condition table с помощью Conditional Statement Syntax, Таким образом, условия оцениваются, и если они оцениваются как истинные, это влияет на уровень установки функции.
    • AppSearch может быть вовлечена установка свойств, которые составляют условия объекта.
    • Для каждой функции, если уровень установки функции ниже или равен настройке INSTALLLEVEL property, тогда функция установлена ​​для установки.
  5. Пользовательские Действия
    • Пользовательские действия вооружены и опасны (моя пропаганда против них), но иногда они являются единственным вариантом (у вас есть что-то очень конкретное, что вам нужно сделать).
    • Пользовательские действия могут изменять состояния объектов различными способами:
    • Я считаю, что все пользовательские действия должны быть выполнены до CostInitialize, Смотрите ссылку прямо ниже.
  6. MigrateFeatureStates
    • Напоследок хочу упомянуть MigrateFeatureStates, Стандартное действие MSI, которое попытается "воспроизвести" состояние установки, выбранное в исходной установке, во время основного сценария обновления.
    • MigrateFeatureStates может быть включен или отключен для настройки на основе настроек в Upgrade table - и, следовательно, он может по-разному влиять на состояние объектов в разных установках.
    • PhilDW напомнил мне, что MigrateFeatureStates могут быть отключены различными другими механизмами.

Некоторые ссылки:

Источник

Короткая версия:

  • Feature F может быть установлен как обязательная функция для Feature 1 (и, возможно, другие).
  • Пожалуйста, проверьте Required Features значение для Feature 1,
  • Для этого просто перейдите в представление "Функции" и выберите Feature 1 - тогда посмотрите на Required Features значение. Если Feature F там указан, то это вызвало бы поведение, которое вы видите.

Ошибка, ошибка - Matrix's Got You:-): Я написал длинный ответ о том, как на выбор функций могут влиять многие вещи для Basic MSI projects, но, читая ваш вопрос еще раз, я почти уверен, что это Installscript MSI project и не Basic MSI project вообще, и причина в поведении диалогового окна функции, которое вы описываете.

Installscript MSI: в верхнем левом углу окна приложения Installshield отобразится тип проекта. Это скажет что-то вроде: "My Project Name-1 - Installshield [InstallScript MSI Project], Не могли бы вы проверить, что это говорит? (последняя часть - внутри скобок - это ключ). Обработка функций довольно различна в двух типах проектов. Installscript MSI projects имеет настраиваемые диалоги Installshield (диалоги Win32), в отличие от стандартных диалогов Windows Installer Basic MSI projects (определено в таблицах). Мне очень не нравятся MSI -проекты Installscript - я нахожу их глючными, но у них есть некоторые приятные особенности. Я бы не стал их использовать. Субъективное мнение. Основные проекты MSI являются стандартными файлами MSI и намного лучше для корпоративного развертывания.

"Необходимые функции": при просмотре представления функций в Installshield для Installscript MSI project, у вас есть больше вариантов, чем для Basic MSI project, Required Features настройка, в частности, оборачивает множество функциональных возможностей, чтобы позволить функциям быть взаимозависимыми друг от друга - что-то, что должно быть реализовано вами в проектах Basic MSI совершенно по-другому. Это поле является ключом к поведению выбора функции, которое вы видите - я в этом уверен. Смотрите ниже предлагаемый подход вперед.

Ведение журнала. Чтобы включить ведение журнала, попробуйте открыть проект, а затем перейдите к Build => Settings... => MSI Log File Теперь нажмите All Error Messages а также Verbose Output и введите имя файла в Log File коробка. Нажмите OK, Теперь попробуйте собрать и запустить свой проект.

Резюме:

  1. Я хотел бы проверить, что тип проекта на самом деле. Установить скрипт MSI - наверное.
  2. Убедившись, что это MSI -проект Installscript, я бы открыл Feature view и проверить Required Features значение для каждой функции в последовательности.
  3. Я предполагаю, что вся логика "автоматическая" из Installshield - вы просто определяете для каждой функции, какие другие функции ей требуются, путем настройки значения " Required Features ".
  4. Казалось бы, если вам не нужна никакая другая логика, Installshield позаботится о выборе функции "автоматически", и вы получите полнофункциональный диалог выбора функции - при условии, что вы правильно определили зависимости функций.
  5. Я не выполнял никаких настроек диалогов MSI Installscript, поэтому не могу вам помочь, но я уверен, что настройка значения " Требуемые возможности " должна стать хорошей отправной точкой для выяснения того, что вам нужно.
  6. Не могли бы вы также проверить Installscript view чтобы увидеть, есть ли там какой-либо пользовательский код, связанный с GUI? И вы можете проверить Custom Actions & Sequences просмотр также - для проверки любой пользовательской логики, реализованной другими способами (VBScripts, PowerShell, JavaScript и т. д.).
Источник
Другие вопросы по тегам