Не выбранная функция устанавливается - PullRequest
0 голосов
/ 24 мая 2018

Я оказался на работе в 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 в качестве единственной опции.Это может произойти и с другими функциями, но Feature 1 устанавливается быстрее всего, поэтому он протестирован с наибольшим количеством.

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

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

Ответы [ 2 ]

0 голосов
/ 28 мая 2018

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

Настраиваемые действия : Исходя из доступной информации (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. Немного лучший подход, на мой взгляд, здесь .Ваша установка может использовать некоторые из этих методов.


Попытка Общий ответ:

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

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

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

  1. Стандарт msiexec.exe Командная строка
  2. GUI настройки взаимодействия с пользователем
    • Диалоговое окно выбора функции графического интерфейса MSI (если доступно в настройке).
    • Некоторые настройки (не все) имеют диалоговое окно «Пользовательский», которое позволяет пользователю выбирать, какие функции устанавливать, а какие нет.
    • На видимые функции можно воздействовать напрямую (и их подфункции - видимые или нет - в зависимости от конфигурации функции - поиск msidbFeatureAttributesFollowParent).
    • Существует несколько возможных состояний функцийустановить в некоторых настройках.Рекламируйте функцию, устанавливайте функцию, не устанавливайте функцию и т. Д. *
    • В графическом интерфейсе настройки могут выполняться пользовательские действия, влияющие на состояние выбора функции (см.раздел пользовательских действий ниже).
      • Например, на основе взаимодействия пользователя, выбирающего одну функцию, другие функции могут быть выбраны - или не выбраны.
      • Для установок MSI Installscript логика для этого встроена (и также настраивается),Для базовых настроек MSI можно сделать что-то подобное, но есть меньше автоматики.
  3. INSTALLLEVEL
    • Следует упомянуть это обязательное свойство настройки .Это базовая линия, определяющая, должна ли быть установлена ​​конкретная функция или нет.Каждая настройка имеет INSTALLLEVEL.
    • Каждая функция имеет свой собственный атрибут уровня , и функция будет установлена, если ее атрибут уровня установлен равным или меньшим номером, чем общий параметр установки INSTALLLEVEL.
    • Как следствие можно повлиять на запрошенное состояние установки для нескольких функций, отрегулировав настройки INSTALLLEVEL.
    • Aплохая, но не редкая практика - это max out INSTALLLEVEL до 32767, чтобы принудительно установить все функции.Это неправильно, потому что некоторые функции могут быть несовместимы с системой (неправильные файлы для неправильной системы).
  4. Условия функции
    • Как уже упоминалось, все функции имеют атрибут level , которым можно манипулировать с помощью условных операторов, которые оцениваются во время выполнения.
    • Это связано с предыдущим пунктом, но наоборот:теперь мы меняем атрибут уровня каждого объекта, а не собственный базовый уровень объекта установки (INSTALLLEVEL).
    • См. столбец уровня в Feature Table.
    • Фактическая условная логика находится в Condition table с использованием Conditional Statement Syntax.Таким образом, условия оцениваются, и если они оцениваются как истинные, это влияет на уровень установки компонента.
    • AppSearch может быть задействован при настройке свойств, составляющих условия компонента.
    • Для каждой функции, если уровень установки функции ниже или равен значению INSTALLLEVEL property, то функция устанавливается для установки.
  5. Настраиваемые действия
  6. MigrateFeatureStates

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

0 голосов
/ 25 мая 2018

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

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

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

MSI Installscript: В верхнем левом углу окна приложения 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. Я бы проверил, какой тип проекта действительно существует.Installscript MSI - вероятно.
  2. После проверки того, что это проект MSI Installscript, я бы открыл Feature view и проверил значение Required Features для каждой функции в последовательности.
  3. Я предполагаю, чточто вся логика «автоматическая» из Installshield - вы просто определяете для каждой функции, какие другие функции ей требуются, путем настройки значения « Обязательные функции ».
  4. Казалось бы, до тех пор, покавам не нужна никакая другая логика, Installshield позаботится о выборе функции «автоматически», и вы получите полнофункциональный диалог выбора функции - при условии, что вы правильно определили зависимости функции.
  5. Я не выполнял никаких настроекInstallscript MSI диалоги, так что я не могу вам тут помочь, но я уверен, что настройка значения « Required Features » должна стать хорошей отправной точкой для выяснения того, что вам нужно.
  6. Не могли бы вы также проверить Installscript view, чтобы увидеть, есть ли там какой-либо пользовательский код, связанный с ГУЯ?И вы можете также захотеть проверить представление Custom Actions & Sequences - проверить наличие любой собственной логики, реализованной другими способами (VBScripts, PowerShell, JavaScript и т. Д.).
...