Внешний обработчик для msiexec MsiSetExternalUI

Доброе утро,

Я пытаюсь добиться внешнего обработчика для msiexec, но не мешаю msiexec действовать иначе. Я хотел бы иметь возможность перехватывать все сообщения, используя MsiSetExternalUI, но все еще с теми же ответами и диалогами для конечного пользователя.

Моя главная цель - перехватить, откуда установлен кэшированный источник для MSI, и переместить их в другое место.

Я попытался использовать ведение журнала, используя раздел реестра, но местоположение пакетов может быть удалено, и источник пакета не будет существовать к тому времени, когда я перехватил файл журнала и получил местоположение MSI.

Например, встроенный msi в установочный exe-файл, особенно старый распространяемый C++, извлекает себя с помощью redist в случайный каталог в корне homedrive и устанавливает, а затем по завершении удаляет каталог. Поведение msiexec не согласовано, так как большинство пакетов кэшируются в установщике Windows dir c:\windows\installer, а исходные пакеты кэшируются в пакетах c:\programdata\cached.

Почему некоторые пакеты кэшируются, а другие нет?

Отсюда и причина, по которой я хотел бы использовать внешний интерфейс, но при этом следить за тем, чтобы поведение оставалось неизменным.

В настоящее время я тестирую проект с

MsiInterop.MsiSetExternalUI(новый MsiInstallUIHandler(_OnExternalUI), MsiInstallLogMode.ExternalUI, IntPtr.Zero);

Любые идеи или примеры будут действительно полезны.

Источник

3 ответа

Решение

Я не могу понять, почему перехват пользовательского интерфейса имеет какое-либо отношение к расположению кэша, которое нельзя изменить во время установки. Однако не совсем понятно, какое использование "кеша" вы намереваетесь здесь. Я предполагаю, что вы ссылаетесь на полный MSI-файл, который, возможно, был извлечен в какое-либо место для установки или находится в том месте, откуда он был установлен.

Предположим, что установка завершена, и вы знаете (или можете получить) его ProductCode. Все, что вам нужно сделать, чтобы получить все официальные местоположения источника, это вызвать MsiSourceListEnumSources (), и он сообщит вам фактические местоположения, которые Windows будет использовать для поиска MSI для обслуживания, обновления, ремонта и т. Д., Если и когда это потребуется.

Если исходный MSI находится в местоположении, которое вы не одобряете, используйте MsiSourceListClearSource (), чтобы удалить эту запись, скопируйте MSI в выбранное вами местоположение, а затем используйте MsiSourceListAddSource (), чтобы добавить это местоположение. Существует множество API-интерфейсов sourcelist для именно этого типа действий управления, например, когда продукты были установлены из сетевых расположений, которые больше не доступны.

Я не верю, что вам следует перемещать или изменять внутренний кэшированный (обфусцированный файл) MSI-файл, который обычно находится в \ windows \ installer. Это нас иногда называют кэшированным местоположением, но вы, похоже, имеете в виду полный MSI, использованный для установки продукта.

Источник

"Намерение"

У нас есть некоторые проблемы в развертывании, когда люди говорят нам, что они делают, но не то, что они намереваются. Иногда это заставляет нас писать сложные ответы, которые не отвечают на вопрос. Я надеюсь, что это не тот случай.

Попытка ответа

Вы хотите найти точный путь к MSI, который кэшируется во время установки, в %SystemRoot%\Installer во время установки вашего MSI?

Я никогда не пробовал, но saschabeaumont опубликовал VBScript давным-давно, который пытается сделать то, что вы хотите (хотя и не во время самой установки): WiX Custom Action - MSI copy. Я никогда не пробовал этот скрипт и не хочу его рекомендовать.

Что касается переадресации C++: я не уверен точно, что они делают, но Microsoft стремится переписывать свои собственные правила все время, и они делают вещи - время от времени - которые не имеют смысла при анализе. Я бы не стал тратить слишком много времени на то, чтобы понять это, если только вам это абсолютно не нужно. Просто мои 2 цента.

Можем ли мы спросить очевидное: зачем вам эта копия? Возможно, есть лучший способ добиться того, чего вы хотите? Ниже приведен небольшой обзор различных папок, используемых для кэширования MSI-файлов, и некоторые ссылки с информацией о MsiSetExternalUI.

MsiSetExternalUI

Я не понимаю, как вам нужно получить доступ к журналу, как вы пытаетесь с MsiSetExternalUI для достижения кэширования вашего файла MSI, но вот несколько ссылок для его использования:

Подробнее о кэшировании MSI

Существует несколько форм кэширования MSI - некоторые встроены в установщик Windows, другие реализуются сторонними инструментами, а некоторые инструменты Microsoft имеют собственный способ развертывания (например, Visual Studio).

Вот несколько советов о том, как файлы MSI могут быть кэшированы в вашей системе. Это ни в коем случае не будет полным, но это то, что я могу списать со счетов:

1. Кэширование установщика Windows (msiexec.exe)

Существует встроенная функция установщика Windows для кэширования копии исходной базы данных установки MSI во время установки. Эта кэшированная копия раньше была удалена из внутренних CAB-файлов (что делало их намного меньшими, чем у исходного файла), но это изменилось в Windows 7, и копии MSI теперь кэшируются в полном размере (для получения подробной информации перейдите по ссылке).

Папка, в которой кэшируются MSI: %SystemRoot%\Installer (обычно C:\Windows\Installer). Каждому MSI присваивается случайное шестнадцатеричное имя. Все файлы MSI попадут в эту папку кэша - если что-то пошло не так во время установки или регистрации продукта. MSI-файл, отсутствующий в этой папке, представляет собой серьезную проблему - продукт обычно не удаляется и не обновляется. Мы начинаем видеть проблемы с определенным программным обеспечением безопасности, изолирующим файлы MSI из этой папки - это может быть кошмаром для решения проблемы - но это не главное для ответа.

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

ОБНОВЛЕНИЕ: Честно говоря, я думаю, что дополнительное кэширование исходных файлов должно было быть встроено в установщик Windows с самого начала и быть параметром командной строки по умолчанию (для пользователей дома и небольшого офиса), и тогда простой флаг мог бы легко предотвратить такое кэширование для все корпоративные пользователи (например, NOSOURCECACHING = 1). Кроме того: теперь, когда файлы MSI кэшируются в полном размере в% SystemRoot% \ Installer - все еще кажется, что вы не можете автоматически получать исходные файлы оттуда? (не проверено в последнее время). Что с этим? Файлы есть - если только установка не произошла из административного образа (в этом случае источник, вероятно, безопасно расположен в общем сетевом ресурсе и доступен при необходимости, чтобы избежать беспорядка на локальном ПК). Ну да ладно, в будущем мы, без сомнения, будем извлекать файлы напрямую из онлайн-репозиториев по требованию, так что одна проблема решена и куча новых в процессе разработки? Вредоносные программы, подмена и инъекция? Удаленные файлы удаляются без предупреждения (чтобы избавиться от уязвимых выпусков, которые больше не должны использоваться - оставляя пользователей в затруднительном положении)? Проблемы с сертификатом и подписью? Проблемы с брандмауэрами и прокси? Обновления авто-магии с неудачными ошибками, которые сразу же бьют всех? Просто разглагольствовать:-). Я уверен, что это будет в значительной степени улучшением. Во всяком случае, далее к текущим сторонним подходам кеширования (не стандарт MSI) в разделах ниже.

2. WiX кеширование

Функция связки WiX (Burn) может кэшировать файлы MSI в системе. Я не уверен на 100%, как они это делают, если честно, я надеюсь, что Арнсон или Меншинг могут поправить меня здесь, если я ошибаюсь. Тем не менее, я считаю, что они используют: %ProgramData%\Package Cache (обычно C:\ProgramData\Package Cache) для их кэширования. В моей системе много разных компонентов Microsoft, и я не уверен, что все они поставляются с WiX.

3. Установить кеширование экрана

Installshield может кэшировать оригинальные файлы MSI в %SystemRoot%\Downloaded Installations для определенных типов конфигураций сборки. Другими словами: не все установки Installshield будут кэшироваться таким образом - это параметр сборки проекта Installshield, который может быть включен или выключен по желанию разработчика программы установки.

ОБНОВЛЕНИЕ: Кажется, более новые версии Installshield теперь могут кэшировать настройки по умолчанию в %LocalAppData%\Downloaded Installations (обычно C:\Users\YOURUSERNAME\AppData\Local\Downloaded Installation) вместо %SystemRoot%\Downloaded Installations, Я не уверен, какая версия перешла на это место. Может быть, Michael Urman из Installshield может помочь нам?

4. Расширенное кэширование установщика

Добавлен Bogdan Mitrache из Advanced Installer (большое спасибо - теперь это точно): Самый простой способ получить / скопировать MSI из EXE- Bogdan Mitrache, созданного Advanced Installer, - это использовать /extract опция командной строки.

Во время установки для сборок EXE (MSI входит в состав EXE) Advanced Installer по умолчанию извлекает содержимое в этом месте:

[AppDataFolder][|Manufacturer]\[|ProductName] [|ProductVersion]\install,

Как видите, это зависит от поставщика, поэтому путь для каждого пакета различен.

Кроме того, этот путь настраивается в рамках проекта установки, поэтому пользователи могут изменять его (в большинстве случаев это не так).

Существует также возможность удалить извлеченные ресурсы после завершения установки, опять же, это настраивается пользователем и включено по умолчанию.

Если вы создаете стандартный MSI с помощью Advanced Installer, то кэширование выполняется установщиком Windows, как описано выше.

5. Кеширование Visual Studio

Visual Studio кеширует пакеты под: %AllUsersProfile%\Microsoft\VisualStudio\Packages (обычно C:\ProgramData\Microsoft\VisualStudio\Packages). Я действительно понятия не имею, как они делают вещи, кроме этой папки. Здесь также есть пакеты: %ProgramData%\Microsoft\VisualStudio\Packages,

ОБНОВЛЕНИЕ: папка %ProgramData%\Microsoft\VisualStudio\Packages похоже на то же место, что и выше (%AllUsersProfile%\Microsoft\VisualStudio\Packages) только с символической ссылкой (папки указывают на те же файлы и папки на диске). Также возможно отключить это кэширование, как описано Хитом Стюартом здесь: Перемещение или отключение кэша пакетов для Visual Studio 2017.

И это не MSI и не всем известно %ProgramFiles(x86)%\Microsoft SDKs\NuGetPackagesFallback

6. Другие папки кэша?

Apple: я не знаю много об этом, но, похоже, Apple может использовать эту папку для кэширования некоторых из своих установщиков MSI: %LocalAppData% \Apple\Apple Software Update\ (обычно C: \ Users \ Acer \ AppData \ Local \ Apple \ Apple Software Update).

Sun: кажется, Sun использует эту базовую папку для кэширования установочных файлов MSI Java: %UserProfile%\AppData\LocalLow\Oracle\Java (обычно C:\Users\Acer\AppData\LocalLow\Oracle\Java).

Без сомнения, многие другие папки кеша используются.

Источник

Спасибо Богдану и Штейну, я не знал о различных типах установщика, использующего разные папки кеша.

Я придумал полу-решение и перенаправить и подключить через внешний интерфейс. Я решил установить только определенные флаги

ExternalUINoDialog = FatalExit | Error | Warning | User | CommonData | Progress from Interop in the msiexec

Это позволяет стандартное поведение в диалоге от ввода пользователя, а также. Я также установил внутренний пользовательский интерфейс, зависящий от переключателей, полученных из аргументов.

Я заметил несколько случайных и единичных случаев, таких как Microsoft, замечательный способ использования:

MsiExec.exe -Embedding /V

У кого-нибудь есть идеи, что за переключатель встраивается? Я пробовал поиск, но основные поиски всегда возвращаются с вирусами и msiexec?

Кто-нибудь знает документацию по MSDN? Я посмотрел на msiexec /? но нет упоминания о встраивании?

Источник
Другие вопросы по тегам