Основной вариант обновления недоступен в типах проектов InstallShield InstallScript
Основное обновление автоматически удаляет существующую версию и устанавливает текущую.
К сожалению, значительное обновление доступно только для следующих типов проектов: - Базовый MSI - InstallScript MSI - База данных MSI - Преобразование
Он недоступен для типа проекта "InstallScript". Как мы можем добиться того, что Major Upgrade предлагает в типе проекта "InstallScript". Мы хотим автоматически удалить существующую версию, прежде чем продолжить текущую установку.
Я пытался использовать функцию Installin UninstallApplication, а также вызывать msiexec из кода InstallScript для удаления вручную перед продолжением установки, но эти два подхода представляют два диалоговых окна. Один для подтверждения удаления продукта, а другой после завершения удаления, где вы нажимаете кнопку Готово, чтобы выйти из удаления.
Нам нужно то, что предлагает Major Upgrade, а не появление диалогов.
Мы не можем использовать тип проекта "InstallScript MSI", поскольку у нас возникают некоторые проблемы с этим типом проекта.
Кроме того, мы не хотим преобразовывать наш существующий проект "InstallSript MSI" в "Basic MSI", поскольку мы хотим повторно использовать имеющиеся у нас сценарии установки, и преобразование в тип проекта "InstallScript" позволило бы нам сделать это.
спасибо за ваш ответ Стейн.
Что касается Basic MSI, я вижу ниже документально подтвержденный InstallShield. Кажется, недостатком является невозможность сохранения информации с использованием некоторых глобальных переменных. В настоящее время у нас есть проект InstallScript MSI, и у нас есть сценарии установки, которые поддерживают информацию с использованием глобальных переменных. Например, мы можем искать и сохранять что-то и на основе этого динамически менять флажки в диалоговом окне и т. Д. Мы также ищем и храним информацию, которая используется позже, когда функции installscript выполняются на разных этапах. Но, похоже, что с "Basic MSI" каждое пользовательское действие, вызывающее функцию InstallScript, является автономным в том смысле, что то, что он обнаруживает и устанавливает, не может быть использовано другим пользовательским вызовом Action для другой функции InstallScript. Какие-нибудь мысли?
Базовый MSI:
Глобальные переменные и указатели больше не поддерживаются между отдельными вызовами пользовательских действий InstallScript. Кроме того, каждый InstallScript
Пользовательское действие инициализирует и использует свой собственный SUPPORTDIR. Таким образом, вы не можете обмениваться информацией между отдельными вызовами с помощью файлов
в SUPPORTDIR. Для получения дополнительной информации см. Глобальные переменные, Глобальные указатели и SUPPORTDIR.
Глобальные переменные, глобальные указатели и SUPPORTDIR
В InstallShield 12 и более поздних версиях, когда установка Basic MSI выполняет настраиваемое действие InstallScript, загружается скомпилированный InstallScript
перед вызовом действия, и оно выгружается после завершения действия. Таким образом, каждое пользовательское действие InstallScript выполняется по-своему
сеанс с полной загрузкой и выгрузкой движка InstallScript. Это поведение отличается от InstallShield 11.5 и более ранних версий:
скомпилированный InstallScript был загружен один раз до того, как было выполнено первое пользовательское действие InstallScript, которое использовалось InstallScript, и он
был выгружен в конце установки после завершения всех пользовательских действий InstallScript.
Основным следствием этого изменения в поведении является то, что глобальные переменные и указатели больше не поддерживаются между отдельными
Вызовы пользовательских действий InstallScript:
• Если вам нужно сохранить значение в нескольких вызовах пользовательских действий, вы должны использовать какой-то внешний механизм, такой как реестр, Windows
Свойства установщика или внешний файл данных для хранения информации между вызовами. Если вы решите использовать свойства установщика Windows в
Отложить, зафиксировать или откатить пользовательские действия InstallScript, см. рекомендации в Свойствах установщика Windows и Отложено, Подтвердить и
Откат пользовательских сценариев InstallScript. • Если вам нужно использовать COM-объект или какой-либо другой глобальный объект при вызовах пользовательских действий, вы должны инициализировать объект для каждого
индивидуальный вызов настраиваемого действия для того, чтобы объект был действительным. Еще одним следствием этого изменения является то, что каждое настраиваемое действие инициализирует и использует свой отдельный SUPPORTDIR. Поэтому вы не можете поделиться
информация по отдельным вызовам с использованием файлов в SUPPORTDIR, поскольку каждый вызов настраиваемого действия будет иметь свой собственный уникальный SUPPORTDIR. Вы
можете поделиться информацией, используя FOLDER_TEMP или другое местоположение файла.
Обратите внимание, что FOLDER_TEMP не может быть одним и тем же путем для всех ваших пользовательских действий InstallScript. Если у вас есть некоторые пользовательские действия InstallScript
которые работают в системном контексте, а некоторые - нет, у них будут разные временные пути, если пакет работает в повышенном состоянии.
Пользовательские действия InstallScript выполняются в контексте другого пользователя, поэтому сохранение файлов во временном каталоге и последующее их получение могут не
работать в определенных сценариях.
2 ответа
Я буду следить за этим ответом и развивать его, поскольку я больше понимаю ваш сценарий. Это будет очень общее:
Надежный бесшумный запуск: надежный бесшумный запуск может быть самым сильным преимуществом MSI. Это, пожалуй, самое значительное улучшение по сравнению со старыми технологиями на основе сценариев.
Файлы ответов: Прошло много времени с тех пор, как я посмотрел на установку Installscript (не MSI), но, по сути, им нужны файлы ответов без вывода сообщений ( справка IS) для правильной работы в режиме без вывода сообщений (по сути, записанный список того, что выбирал пользователь в каждом из них). диалоговое окно настройки), и они не всегда надежны (скажем, специальное условие на машине вызывает диалоговое окно, которое не было записано в исходном цикле при записи файла ответов). Вы должны записать файл ответов в режиме без вывода сообщений как для установки, так и для ее удаления (они будут отличаться - некоторые люди пытаются использовать файл ответов для установки - это не работает).
Совет: я не совсем понимаю вашу общую ситуацию. Похоже, вы вообще не используете MSI, но хотите обновить функциональность? Базовые проекты MSI могут содержать любое количество пользовательских действий Installscript - без проблем. То, что вы теряете, в верхней части моей головы, это ряд событий, которые доступны в Installscript MSI (и более старых проектах Installscript) и диалоговых окнах Win32, которые представлены в установках Installscript. Базовый MSI - намного лучший тип проекта, потому что он является стандартным MSI и намного менее глючит, чем Installscript MSI.
Установочные скрипты можно вызвать из сценариев Basic MSI, вставив пользовательское действие, которое ссылается на экспортированную функцию Installscript. Просто добавьте новый файл setup.rul в ваш проект установки, а затем экспортируйте функции, которые вы хотите вызвать из пользовательского действия:
export prototype MyFunction(HWND); <= теперь эта функция может быть вызвана из пользовательского действия.
Есть комментарии в setup.rul файл, объясняющий весь процесс. Просто создайте пустой проект Basic MSI, а затем вставьте новый Setup.rul файл для изучения.
Стейн, кажется, вы говорите, что Major Upgrade специфичен для MSI и, следовательно, ожидал, что в проектах 'InstallScript' этого не будет.
В таком случае, могу ли я спросить, есть ли что-то еще, что можно использовать в типах проектов "InstallScript", что позволит нам достичь того, что предлагает Major Upgrade, то есть автоматически удалить существующую версию, прежде чем приступить к установке с текущей версией?