Используя MSI также делает исправление (файлы MSP) и обновляет легче. MSI используют понятие уникального продукта и кодов Обновления, который делает целый процесс легче.

Некоторые системы развертывания (Доставка CA Unicenter Software является одним примером) могут также понять MSI специальным способом, который позволяет им интегрироваться намного лучше в систему развертывания. Например, можно подать MSI в библиотеку программного обеспечения системы развертывания, и это автоматически обнаружит различные функции в продукте и автоматически позволит намного больше детализированных пользовательских действий (Локальная Установка, Проверит, Восстановление и т.д.), и вход.

Самовосстановление / восстановление является также майором плюс для MSI.

Кроме того, открытый исходный код выезда Windows Installer XML, "набор инструментов, который создает пакеты установки Windows из исходного кода XML. Набор инструментов поддерживает среду командной строки, которую разработчики могут интегрировать в их процессы сборки для создания MSI и установочных пакетов MSM". Это используется MS для подготовки нескольких из его главных пакетов программного обеспечения.

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

для наблюдения, что люди делают с msis [или необслуживаемое развертывание], посещают, например, этот сайт, и это - форумы.

ОБНОВЛЕНИЕ, июль 2018: чрезвычайно сжатая сводка ниже информации доступна на stackoverflow: Главные Преимущества MSI ("executive summary" - своего рода).

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

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

Я также хочу предложить эту статью MSDN в качестве хорошего чтения: Windows Installer: Преимущества и Реализация для Системных администраторов.

Стандартизация:

Одним словом, MSI о стандартизации, и о контакте с запахами "развертывания" технологий установщика прежней версии. Целый набор плохих проектов архитектуры установки, которые вызвали повторные проблемы развертывания.

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

Одни только эти функции составляют крупное улучшение по сравнению с предыдущими технологиями установки, которые рассматривали удаление и тихое выполнение случайно - возможно, самые важные функции корпоративного развертывания наряду с надежным удаленным управлением пакетом через Active Directory или выделили инструменты удаленного администрирования, такие как Microsoft SCCM (раньше SMS), IBM Tivoli, CA Unicenter и подобный.

Кто-то копировал предыдущую версию этого ответа. Возможно, более быстрое чтение?

Установщики прежней версии "запахи развертывания"

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

• 1) они иногда понижали и перезапись совместно использованные и имеющие версию файлы с небольшим беспокойством о dll-аде, который закончился
• 2) часто была не надлежащая стандартная программа удаления, предоставленная установщиком, или это не завершалось правильно и надежно - особенно, если выполнено тихо. Это - очень большая проблема для корпоративного управления SOE
• 3) установка без диалогов редко поддерживалась правильно. Надежность была плоха, и один часто должен был записывать выполнение установки с диалоговыми выборами, и это не имело дело хорошо с неожиданными условиями, такими как ошибочные диалоговые окна или предупреждение диалоговых окон, что не был зарегистрирован в исходном выполнении
• 4) установщик не вел учета того, что было установлено и следовательно не было никакого автоматического способа проверить файлы на диске, чтобы проверить, были ли они все еще версиями, которые были установлены первоначально установщиком
• 5) они показали непредсказуемые, ненадежные и нестандартные параметры командной строки для исполняемого файла установки
• 6) следование из нестандартной командной строки и отсутствия стандартов было трудно настроить установщики с определенными значениями, необходимыми для корпоративного развертывания надежным и предсказуемым способом
• 7) обычные пользователи не могли выполнить эти установки, и один часто должен был бездельничать с временными правами администратора (использование, "выполненное как", если бы это было достаточно, или войдите в систему как администратор, установите и затем выйдите из системы - этот полный вход в систему и представьте поколение, иногда требовался для установки завершиться),
• 8) установщик setup.exe часто не возвращал бы надлежащий код ошибки или код успеха, и иногда он сразу выйдет и удар другого процесса, который закончил бы установку, мешающую определить, была ли установка завершена - особенно через пакетный файл
• 9) большинство файлов setup.exe позволило файлам быть извлеченными, но не надежным, предсказуемым способом - обычно необходимо было проводить много времени, находя, что право переключается, чтобы сделать его
• 10) вход был обычно плох и довольно случаен в некоторых инструментах. Отладка с файлами журнала редко производила ясность, но действительно помогала немного
• 11) не было никакой прозрачности в том, что установщик делал и никакой или ненадежный откат для отмены изменений после неудавшейся установки
• 12) не было никакого промышленного стандарта способ развернуть совместно использованные компоненты во время выполнения, были ли они компонентами операционной системы, сторонними компонентами или Вашим собственным

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

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

Преимущества MSI - краткое изложение

На простом языке действительно важные преимущества MSI (без определенного порядка):

• 1) удаление всегда доступно для каждого пакета, если это активно не отключено
• 2) это - то же для входа, который является большим и стандартизирован, хотя подробный (инструменты, такие как WiLogUtl.exe могут использоваться для анализа файлов журнала),
• 3) какой файл MSI делает (полу-) прозрачен или "inspectable" по большей части. Исключением являются пользовательские действия - (см. раздел прозрачности ниже),
• 4) настройка установки сделана в стандартизованном способе (преобразовывает)
• 5) нет никакой потребности смешать с временными правами администратора, так как выполнения установки подняли с помощью рекламы Active Directory, групповой политики или удаленного администрирования. Некоторые квалификации здесь. Также см. этот снимок экрана из редактора объектов групповой политики.
• 6) тихая установка / удаление через инструменты управления или использование msiexec.exe работает хорошо
• 7) существует полная поддержка отката неудавшихся установок. Если Вы устанавливаете вручную на поле существуют некоторые квалификации, о которых необходимо знать.
• 8) файл MSI предоставляет себя и контролю и проверке для непротиворечивости и логической законности, так как они соответствуют схеме базы данных (см. пример проверки),
• 9) обновления стандартизированы типы, хотя комплекс и часто подверженные ошибкам для неопытных поставщиков программного блока
• 10) извлечение файлов от msi является встроенной функцией (проверка связанная статья для хорошего быстрого обзора)
• 11) командная строка Windows Installer, msiexec.exe, функции очень мелкомодульное управление того, как последовательность установки должна быть выполнена, и вся работа опций со всеми стандартами совместимые файлы MSI (уровень журнала набора, выполнение тихо / в интерактивном режиме / полутихо, установленные параметры установки, применяется, преобразовывают и т.д....).
• 12) модули слияния являются механизмом MSI для обеспечения совместно используемых файлов с несколькими пакетами MSI. Это - потребляемый модуль или пакет логики установки, mergeable с любым пакетом MSI во время компиляции. Wix расширился и изменил к лучшему это понятие с использованием Wix, включают файлы - понятие, которое, по-моему, превосходит модули слияния - специально для Ваших собственных файлов (т.е. не файлов ОС)
• 13) сам механизм установщика Windows показывает механизм для предотвращения перезаписи имеющие версию или измененные файлы на установке. Этим управляет довольно сложная заменяющая логика файла. Хотя эффективный и хороший, логика может закончить тем, что была проблемой в и себя, так как многие разработчики сталкиваются с проблемой неспособности перезаписать их измененные файлы конфигурации при обновлении. Решением этих проблем являются обычно незначительные изменения в проектировании приложений для предотвращения антишаблонов обычного развертывания - хотя это - большое собственное обсуждение.

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

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

Прозрачность (открывают формат установщика),

Файл MSI является по существу разделенным вниз база данных SQL-Server, сохраненная как файл COM-СТРУКТУРИРОВАННОГО ХРАНИЛИЩА - по существу файловая система в файле или наборе потоков данных. Это - тип файла, используемый в документах Microsoft Office, и он приводит к стандартному формату, который может быть рассмотрен и осмотрен - огромная проблема для крупных корпораций.

За исключением скомпилированных пользовательских действий файл MSI является белым полем. Если установка изменяет что-то сумасшедшее, такое как параметры сети в масштабе всей системы, можно на самом деле видеть, что он использует соответствующие инструменты. Существенное исключение является скомпилированными пользовательскими действиями - которые являются черным квадратом. Требования логотипа Windows требуют, чтобы пользовательские действия были аннотированы для объяснения, что они делают, но это часто игнорируется разработчиками установки. Надо надеяться, появление Wix улучшит это.

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

Настраиваемость (преобразовывает)

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

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Быстрое объяснение параметра:

/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.

Управление и создание отчетов

Windows Installer поддерживает всеобъемлющую базу данных всех объектов, которые продукт установил в реестре (HKEY_CLASSES_ROOT\Installer - никогда ничего не изменяют здесь непосредственно! Это идет для экспертов также).

Можно надежно определить, установлен ли продукт, какие функции были установлены, и какие версии файла были установлены. Кроме того, можно получить список любых патчей, которые были применены к основному продукту, если таковые имеются. Можно получить доступ к этой базе данных через поддержку API Win32, COM или.NET с помощью разнообразия сценариев, инструментов конфигурирования и административных средств, таких как Microsoft SCCM, IBM Tivoli, CA Unicenter и т.д...

Безопасность (временные поднятые права)

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

Всесторонняя база данных установки также гарантирует, чтобы у Вас был полный обзор установленных патчей и поэтому возможности обнаружить уязвимости системы обеспечения безопасности через средства автоматизации и административные средства.

Проверка

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

Упругость (Самовосстановление)

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

Существуют также типичные проблемы с этой функцией упругости. Большинство администраторов испытало машины с циклическими саморемонтными циклами, которые никогда, кажется, не останавливаются. Перейдите по ссылке для длинного списка причин этой проблемы. И снова, вот более короткая версия, которую могло бы быть легче считать.

Откат

Установка файла MSI обычно инициирует создание точки восстановления. Кроме того, все файлы и объекты реестра, замененные или перезаписанные во время установки, будут сохранены и восстановлены, если установка не завершится, запрещая какие-либо изменения, сделанные в пользовательских действиях.

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

Откат гарантирует, что рабочую станцию оставляют в устойчивом состоянии, даже если установка должна перестать работать. Фактический сценарий отката хранится в скрытой папке непосредственно на системном диске - обычно C:\Config.MSI, и это содержит файлы с расширениями.RBS и.RBF - Файлы Сценария Отката. Как Вы могли бы ожидать, плохо разработал файлы MSI, может нарушить встроенные функции Windows здесь, видеть мое другое сообщение в этом потоке для получения дополнительной информации.

Существуют способы отключить откат и ускорить установку. Не обычно рекомендуемый, но вот детали о свойстве MSIFASTINSTALL и DISABLEROLLBACK. Это - сложная функция, но здесь является быстрым обзором отката.

Исправление и Обновления

Хотя очень сложный, исправление в установщике Windows полностью организовано и зарегистрировано в системе так, чтобы системное состояние защиты могло быть определено путем проверки того, что было установлено. Обновления стандартизированы к нескольким основным вариантам, и это позволяет обновлениям быть выполненными с более высокой степенью уверенности, если Вы можете обработать включенную сложность. Системы развертывания смогут сообщить, что обновления привели к сбою и почему.

В субъективном представлении исправление работает хорошо на 2 основного использования: 1) маленькие текущие исправления для поставленных продуктов и 2) исправление установленного продукта для фиксации его дефектной последовательности удаления, которая предотвращает продукты чистое удаление.

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

Вход (подробный действительно)

Windows Installer обеспечивает стандартизированную функцию входа, которая значительно превосходит предыдущие воплощения, хотя почти чрезмерно подробный. Файлы журнала могут быть дешифрованы с помощью журнала анализаторы, и пользовательские уровни журнала могут использоваться для устранения генерирующих слишком больших файлов журнала с ненужной информацией. Для отладки целей подробный вход чрезвычайно полезен. См. блог Rob Mensching для хорошего ручного способа считать файл журнала MSI (по существу, Вы ищете "значение 3" в файле журнала). Вот демонстрационная командная строка, которая выполняет подробный вход:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

Эта статья от Robert Macdonald от Команды Windows Installer настоятельно рекомендована как практический взгляд на вход MSI: Как Интерпретировать Журналы Windows Installer.

Заключение

Не все хорошо о Windows Installer. Его сложность может время от времени быть чрезвычайной, но для крупных корпораций файлы MSI значительно превосходят любую другую форму развертывания при принятии во внимание списка преимуществ выше.

Новая парадигма установщика (огромный SQL-оператор)

Для понимания новой "парадигмы", важно понять, что MSI предназначается как декларативное описание того, что собирается произойти в целевой системе, а не фиксированной последовательности событий. Я предполагаю, что можно думать о нем как об огромном SQL-операторе. Например, Вы объявляете объекты, которые Вы хотите добавленный или измененный в файл INI. Поскольку изменения выполнений установки прослежены, и откат доступен так, чтобы изменения могли вернуться, если установка перестала работать. Это действительно работает как "автоволшебство" и надежно, когда сделано правильно.

Пользовательские действия (обычные подозреваемые)

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

В дополнение к встроенным функциям MSI все больше пользовательской функциональности теперь доступно через новую платформу, такую как Wix - способ XML скомпилировать файлы MSI, таким образом, существует все меньше и меньше потребность в сложной логике пользовательского действия для большинства операций.

Полная поддержка функций MSI обработки слияния ini настроек файла, шрифтов, переменных среды, ключей реестра, информации о COM, ярлыков, расширений файла, запускает условия, установку GAC, ODBC, и т.д...

WIX идет далее с поддержкой очень расширенных функций, таких как расширения SQL-сервера, установки IIS и конфигурация, счетчики производительности, проверка DirectX и другие связанные с игрой задачи, собственное формирование изображения.NET, COM +, драйверы, правила брандмауэра, расширения PowerShell, закрытие приложения, управление пользователями, группами, долями и многое другое. Несколько включенный для контакта с, но намного более надежный, чем собственные действия.

Избегайте пользовательских действий по всей стоимости, если возможно

Пытаться поместить его в перспективу: эти встроенные и готовые решения сделаны лучшими доступными экспертами по развертыванию, и они тестируются тысячами, десятками тысяч или возможно даже миллионами пользователей (для встроенного материала в самом MSI). Вы действительно думаете, что можно сделать лучшее создание собственных действий? Используя пользовательское действие должен быть редкий случай, и должно быть абсолютно необходимо достигнуть чего-то уникального для продукта, который Вы устанавливаете. И необходимо записать надлежащую поддержку отката также, которая вполне включена.

Запись пользовательского действия является почти всегда ошибкой, но существуют подлинные случаи при реальной необходимости в гибкости также. Поскольку всегда важно выбрать Ваши сражения хорошо. Это могла бы быть забавная задача сначала, но Вы будете, вероятно, сталкиваться со многими неожиданными проблемами и тратить впустую много дорогостоящего времени. Я имею в виду это очень серьезно. Я записал комплект пользовательских действий C++ для корпоративного использования сам (для устранения подверженных ошибкам пользовательских действий VBScript) - это не обход в парке, и хотя кодирование не может быть самым трудным в мире, отладке и тестировании, и сцепление в фактический файл MSI является не чем иным как чрезвычайно включенный. Некоторое время, исследуя, какие готовые опции доступны, вероятно, сохранит Вас недели технической разработки и приведет к намного большей надежности развертывания.

Используйте последовательность запуска приложения

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

Ваша установка не должна настраивать приложение, она должна подготовить приложение к конфигурации на первом запуске. Конкретно Ваша установка должна записать все настройки, которые требуют поднятых прав - пишущий в HKLM, регистрируя сервисы, устанавливая на путях на машину и любых таких вещах, которые приложение не может записать самостоятельно с правами обычного пользователя.

Если Вы - разработчик установки, необходимо предложить принимать участие, кодировав последовательность запуска приложения вместо того, чтобы писать пользовательские действия установки. Если ничто иное, чтобы не быть похожим на Вас, не пытается "переложить ответственность" на кого-то еще. В этой последовательности запуска можно написать намного более надежный и тестируемый код, который легче заставить справку от персонала QA тестировать (они часто не понимают тестирование развертывания, а также тестирование приложения).

Сложность установки

Ядро сложности установки центрируется вокруг того, что ошибки кумулятивны (Вы справляетесь с процессом доставки, не только, быстрое перекомпилировало), ошибки очень трудно отладить (никакой доступ к системам, где ошибки происходят), и целевые состояния системы отличаются примерно каждым вообразимым способом. См. этот ответ для более полного обсуждения этой сложности и как целевые системы могут осторожный в шокирующем количестве путей: Windows Installer и создание WiX и Сложность Развертывания (см. к нижней части).

WiX (лучшее решение MSI в некоторых целях)

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

N.B: Посмотрите в другом месте в потоке для быстрого краткого изложения проблем общего умысла с файлами MSI - это очень неполно, но должно стоить чтения. Я не хотел добавлять, что к этому ответу, так как это не связанных 100%, но для использования реального мира, это - решающая тема.

Некоторая базовая информация о MSI для системных администраторов:

(простите бесстыдное "продвижение" - это для легкого доступа и извлечения),

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

• Как я могу устранить огромные, кэшируемые файлы MSI в C:\Windows\Installer? (высокое дисковое использование MSI)
• Как ускорить установки MSI (просто несколько опций)
• Как извлечь файлы из setup.exe (стоящий чтения для любого администратора, вероятно, старые новости)
• Различные способы удалить MSI (удаляют ссылку, популярную - высокое количество представлений),
• Как обойти msiexec.exe при контакте с пакетами MSI (автоматизация MSI и сценариях)
• Почему MSI требует, чтобы исходный .msi файл возобновил удаление? (общий вопрос)
• Почему там несколько процессов msiexec.exe в списке процессов во время установки? Что они все делают?

Специальные темы с практическими рекомендациями:

• Принуждение обновления файла, который изменяется во время его начальной установки (общий вопрос)
• Должен там так или иначе заставить msiexec отзываться эхом к stdout вместо того, чтобы регистрироваться в файл (усовершенствованная тема, с помощью внешнего gui для MSI, большего количества содержания разработчика)
• Я хочу установить MSI дважды (экземпляр преобразовывает, или виртуализируйте - серьезно :-)).
• Как обновить каждое использование профиля пользователя ActiveSetup (несколько опасный, но полезный)
• Распространенные ошибки в пакетах MSI (больше для разработчиков, но также и для системных администраторов)
• Как отладить циклическое самовосстановление (важная тема)

Концептуальные Темы / Лучшая практика:

• Каковы преимущество и реальная цель установки программы? (основы развертывания)
• Цель Административных Установок (базовая операция MSI для системных администраторов)
• Почему Вы не должны использовать MSI для тонких настроек реестра (рекомендуемый чтение)
• Какой продукт установки использовать? (Достоинства и недостатки различных инструментов)
• Почему саморегистрацию считают вредной в MSI

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

Типичные проблемы и недостатки дизайна замечены в пакетах MSI

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

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

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

Типичные ошибки в MSI (без определенного порядка - и представлены как реальная путаница действительно):

• ошибки создания компонента (не следующий лучшей практике). Это может вызвать проблемы для исправления и обновлений с таинственными признаками, такими как недостающие файлы и настройки или патчи, которые разбомбили с бессмысленными ошибками. Для упрощения нужно использовать один файл на компонент, если количество файлов не огромно.
• проблемы обновления, касающиеся пользовательских перезаписываемых данных или сброс. Посмотрите больше деталей ниже.
• неправильное планирование пользовательских действий вне "проведенного раздела" последовательностей установки или пользовательских действий неправильного типа помещается неправильно. Это часто заставляет действия перестать работать (никакие поднятые права), когда выполнено удаленно через системы развертывания, и откату эффективно наносят вред, потому что только проведенные действия откатываются. Транзакция Windows Installer (думают фиксация транзакции базы данных), выполнения между стандартными действиями InstallInitialize и InstallFinalize в основной последовательности установки и выполнениях с поднятыми правами. Все изменения в системе состоят в том, чтобы произойти в этой транзакции - что-либо еще ошибочно (но к сожалению довольно распространено).
• использование непосредственных пользовательских действий режима для внесения изменений в систему вне проведенной последовательности установки. Это повреждает поддержку отката и обычно инициирует ошибки безопасности, так как непосредственные пользовательские действия режима не работают с поднятыми пользовательскими правами, неважно, куда они размещаются в последовательности установки.
• ошибочные проекты, которые заставляют повторяющиеся циклы самовосстановления не происходить ни по какой очевидной причине. Вот другая статья об этом предмете из installsite.org
• пользовательские действия, которые не повинуются подавлению GUI в режиме установки без сопровождения, могут показать модальные диалоговые окна что развертывание причин для сбоя полностью, когда выполнено тихо. Эта проблема наряду с полным различием между "тихим" режимом и интерактивным режимом описана более подробно здесь (несколько подробный и многоречивый): Удаление от Панели управления отличается от, Удаляют из .msi
• некоторые пользовательские действия в ошибочно созданных пакетах вставляются только в последовательности пользовательского интерфейса. Это заставляет их не быть выполненными в режиме установки без диалогов. Это серьезно для корпоративного развертывания, так как тихая установка используется здесь почти исключительно. Эта проблема может также влиять на удаление, означающее Вас, вероятно, придется выполнить удаление в интерактивном режиме, чтобы удаление гарантировало все выполненные пользовательские действия очистки. Снова, см. ссылку в предыдущем пункте маркированного списка для более длинного описания уровней пользовательского интерфейса.
• установка содержит файлы, которые не предназначаются, чтобы быть развернутыми в месте, на котором они устанавливают. Обычно системные файлы, которые должны быть установлены бок о бок в winsxs папке блока.
• медленная скорость установки является другой "проблемой", о которой многие сообщают с MSI. Вот некоторые подсказки относительно предмета. Полные функции Windows Installer довольно мало служебные из-за тяжелых регистрационных требований в реестре для того, что устанавливается.
• перезапись специализированной информации или файлов совместно используемых данных. Это может произойти, если файл INI установлен через Таблицу файлов а не таблицу IniFile, например. В последнем случае это рассматривают как "транзакция изменения" в бывшем случае, это - заменяющая операция файла, которая является обычно неправильной, если Ваши функции файла INI нестандартное форматирование или большие разделы комментариев, которые Вы хотите развернутый с Вашим файлом (характерный для определенных инструментов разработчика).
• сложные правила для перезаписи файла могут заставить файлы быть перезаписанными неумышленно или не обновленными вообще - это - классическая проблема MSI. Проверьте эту статью на то, как можно вызвать, перезаписывают файл, который не обновит. Правила могут немного настроить пользовательские настройки для набора свойств REINSTALLMODE на уровне командной строки msiexec.exe (перезапишите более старые версии, перезапишите равные версии, перезапишите любую версию и т.д....), и они работают по-другому на файлы данных и имеющие версию файлы. Детали в SDK. Понимание этого очень важно, и это - дизайн, часто осуждаемый, даже когда понято.
• сам регистрация файлов COM во время установки может инициировать предупреждения системы безопасности или вызвать проблемы различными способами. Проверьте эту статью: саморегистрация, которую рассматривают вредной.
• вариация на заменяющую проблему файла имеет место, когда значительное обновление (который удаляет и переустанавливает продукт) удаления измененные файлы, и переустанавливает версии по умолчанию. В этих случаях смотрит содержание, вернулся или перезаписанный, когда на самом деле оно было удалено сначала и затем переустановлено.
• сервисы, работающие с пользовательскими удостоверениями пользователя, могут потерять свои учетные данные во время сценариев значительного обновления, а также иметь файл настроек (появитесь к), вернитесь для установки по умолчанию (они были действительно удалены и переустановлены). Только для справки: по-моему, сервисы, работающие с удостоверениями пользователя, являются недостатком дизайна во-первых.
• общественные собственности не передаются правильно от клиента к серверному процессу, препятствующему тому, чтобы пользовательские действия завершились как ожидалось. Это включает обновление свойства SecureCustomActionProperties.
• Некоторые приложения не могут работать правильно за другими пользователями, чем тот, который установил установку первоначально. Это - серьезная ошибка дизайна, но может обычно фиксироваться опытными поставщиками программного блока приложения, использующими самовосстановление или ActiveSetup для добавления ключей реестра HKCU и файлов профиля пользователя. Это - довольно сложный предмет и может потребовать, чтобы немного черной магии получило работу. Для записи: действительное решение, по-моему, состоит в том, чтобы изменить само приложение, чтобы смочь инициализировать все настройки в расчете на пользователя на основе настройки по умолчанию и шаблонов, скопированных с местоположения на машину или на основе приложения внутренние значения по умолчанию (от исходного кода).
• Некоторые файлы MSI портят безопасность для установленных файлов путем установки полных прав чтения-записи для неадминистраторов здесь, там и везде. Другие времена приложение прекращают работать над более новыми версиями Windows из-за недостающих полномочий. Поставщики программного блока приложения сталкиваются с анализом пользовательских потребностей разрешения приложения довольно часто. Обычно некоторое дополнительное управление правами требуется в HKLM или где-нибудь в %ProgramFiles %
• Некоторые установки Installshield назад в день попытались бы соединиться с Интернетом во время установки. Это ужасно для корпоративных сценариев развертывания, где развертыванием плотно управляют, и установщику никогда не будут позволять загрузить новое содержание непосредственно с Интернета.
• Другая сетевая проблема состоит в том, когда установки пытаются показать GUI, где люди вводят данные, которые проверены через Интернет, как они устанавливают, или только показать живое содержание с их веб-сайта. Это обычно - адреса электронной почты, контактная информация, лицензионные ключи и такие вещи. Связь может прерваться полностью по многим причинам, часто из-за недостающей конфигурации прокси в корпоративных средах (нет никакого прямого подключения к Интернету, весь Интернет-трафик направляется через определенный сервер кэширования, и каждый процесс должен обеспечить учетные данные для прохода через брандмауэр). Вот статья об опасностях проверки лицензий через установку.
• Installshield раньше устанавливал время выполнения для его языка Installscript. Эта необходимая как условие установка обычно включалась в setup.exe, и это был легендарный источник проблем. Было много версий, несколько несовместимостей, и раньше происходили много ошибок периода выполнения. Начиная с версии 12 (или поблизости) это время выполнения теперь установлено надежно, и это или компилирует в собственный компонент или работает поигравший в песочнице (я не уверен который, один или другой - вероятно, поигравший в песочнице) надежным способом. Более старые установки Installshield могут отобразить эту проблему развертывания все же. Существует сайт поддержки прежней версии от Installshield для проблем, таких как они: http://consumer.installshield.com/common.asp
• Несколько установок могут отобразить ошибочное поведение установки или неустойчивые ошибки при выполнении на машинах, настроенных для различных языков, чем английский язык, или даже когда Вы выполняете локализованные (переведенные) версии установок на английских машинах. Это может быть чисто отказом во время выполнения, или случаи, когда локализованная функция диалоговых окон отключила текст или ошибочное форматирование или дефектный перевод или много других типов ошибок, касающихся языковой локализации - целая область знаний самостоятельно (переводят текст в изображениях, переведите само программное обеспечение, переведите рекламный материал, соглашение с запросами международной поддержки, адаптацией к настройкам языка в ОС, и т.д....). Некоторым языкам нужно целое приложение, измененное для составления их особенностей языка - типичными проблемами являются строковые макросы и настройки кодовой страницы, последнее существо меньше проблемы с введением Unicode. См. демонстрационный снимок экрана от инструментального средства для перевода.
• Почти все установки приводят несколько к сбою из встроенной валидации, которая доступна для тестирования качества пакетов MSI. См. эту статью для практического примера проверки.
• Иногда обновления перестали работать для MSI вследствие того, что только 3 цифры номера версии MSI на самом деле проверяются во время сканирований значительного обновления.
• Установка файлов INI является встроенной функцией Windows Installer. Записи могут быть добавлены, удалены, объединены или имели дело с любым необходимым способом. Однако файлам INI довольно свойственно быть установленным как файл вместо как сегментированные значения. Это может заставить файл INI быть перезаписанным во время, переустанавливают, вместо того, чтобы быть обновленным. Очень общая проблема MSI.
• Вышеупомянутая проблема также имеет место для приложения.NET и их файлы Config.xml. В этом случае MSI НЕ имеет встроенного способа обновить содержание подробным способом и Вами или должен кодировать обновление через пользовательское действие или заменить целый файл на установке. Wix может иметь новые возможности для этого, но механизм Windows Installer не имеет этого встроенным.

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

Проверьте статью Windows Installer Best Practice из MSDN.