Поделиться через

Рекомендации по установщику Windows

  • Статья

В этом разделе перечислены советы, связанные с основной документацией по пакету SDK установщика Windows, чтобы помочь разработчикам приложений, авторам установки, ИТ-специалистам и разработчикам инфраструктуры найти рекомендации по использованию установщика Windows:

Обновите версию установщика Windows.

  • Используйте установщик Windows 5.0 в Windows Server 2008 R2 и Windows 7. Это версия установщика Windows, предоставляемая операционной системой.
  • Используйте установщик Windows 4.5 в Windows Server 2008, Windows Server 2003 с пакетом обновления 1 (SP1), Windows Vista с пакетом обновления 1 (SP1) или Windows XP с пакетом обновления 2 (SP2). Сведения о получении последней версии установщика Windows см. в разделе "Распространяемые компоненты установщика Windows".
  • Используйте установщик Windows 3.1 в Windows 2000 с пакетом обновления 3 (SP3). Установщик Windows версии 3.1 имеет функции, упрощающие обслуживание и исправление приложений.
  • Многие важные функции появились в версии 3.0 и перечислены в разделе "Не поддерживается" в установщике Windows версии 2.0. Пакеты установки и обновления, созданные для установщика Windows 2.0, можно установить с помощью установщика Windows 3.0 и более поздних версий. Пакеты исправлений, содержащие новые таблицы, используемые установщиком Windows 3.0, по-прежнему можно применять с помощью более ранних версий установщика Windows, но без функций исправления Windows Installer 3.0. Также можно создавать исправления, которые явно требуют установщика Windows 3.0, который не может применяться более ранними версиями установщика Windows. Если пользователь не может обновить версию установщика, убедитесь, что ваше приложение или обновление будет совместимо с будущим обновлением установщика Windows.
  • Список компонентов установщика Windows, которые не поддерживаются более ранними версиями установщика Windows, см. в статье "Новые возможности установщика Windows".

Соблюдайте требования к сертификации логотипа Windows.

  • Даже если вы не собираетесь отправлять приложение в программу логотипа, следуя рекомендациям по сертификации логотипов, вы можете улучшить пакет установщика Windows. Общие сведения о требованиях к логотипу и ссылки на определенные программы сертификации логотипов см. в разделе "Установщик Windows" и "Требования к логотипу".

Подготовьте пакет для локализации.

  • Рекомендуется подготовиться к будущей локализации при создании исходного пакета установки. Вы можете следовать предлагаемой процедуре локализации пакета в локализации пакета установщика Windows.

Обновите средства разработки и документацию установщика Windows.

  • Средства разработки установщика Windows не распространяются, и вы должны использовать только версии этих средств, доступные корпорацией Майкрософт. Они доступны в компонентах пакета SDK для Windows для разработчиков установщиков Windows в пакете sdk для Microsoft Windows (SDK).
  • Несколько независимых поставщиков программного обеспечения предлагают средства для создания или изменения пакетов установщика Windows. Эти средства могут предоставить среду разработки пакетов, которая может быть проще использовать, чем средства, предоставляемые в пакете SDK установщика Windows. Дополнительные сведения об этих средствах можно узнать из информационных ресурсов, рассмотренных в других источниках сведений установщика Windows.
  • Возможность создания пакета из текстовых файлов может быть более интуитивно понятным для некоторых разработчиков. Набор инструментов установщика Windows (WiX), доступный в Sourceforge.net создает пакеты установки Windows из исходного кода XML.
  • Документация в пакете SDK установщика Windows обновляется чаще всего.
  • Используйте последнюю версию Msizap.exe (версия 3.1.4000.2726 или более поздняя), которая доступна в компонентах пакета SDK для Установщика Windows для Windows Vista или более поздней версии. Меньшие версии Msizap.exe могут удалять сведения обо всех обновлениях, примененных к другим приложениям на компьютере пользователя. Если эти сведения удалены, эти другие приложения могут быть удалены и переустановены для получения дополнительных обновлений.
  • Редактор таблиц базы данных Orca.exe — это редактор таблиц базы данных для создания и редактирования пакетов установщика Windows и модулей слияния. Он имеет базовый интерфейс графического интерфейса, но поддерживает расширенное редактирование баз данных установщика Windows. Даже если вы используете другое приложение в качестве основного средства разработки, вы можете найти использование Orca.exe удобно при устранении неполадок и тестировании пакета.
  • Дополнительные сведения о установщике Windows см. в блогах, технических чатах, новостях, технических статьях и веб-сайтах.

Если вы решите перепаковать устаревшее приложение установки, следуйте рекомендациям по перепаковке.

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

  • Средства перепаковки преобразуют устаревшие установки в пакет установщика Windows, сфотографируя промежуточную систему до и после установки. Все изменения реестра, изменения файлов или системные параметры, возникающие во время процесса записи, включаются в установку. Настройте оборудование и программное обеспечение компьютера, используемого для перепаковки установки как можно ближе к системе предполагаемого пользователя. Создайте отдельный пакет для каждой конфигурации оборудования. Перепаковка с помощью чистого промежуточного компьютера. Удалите ненужные приложения. Остановите все ненужные процессы. Закройте все неисключаемые системные службы.
  • Всегда создайте копию исходной установки перед началом работы над ней. Всегда работает над копией. Никогда не остановите перепаковку перед завершением сборки пакета. Если перепаковщик повредит пакет, у вас по-прежнему будет исходный.
  • Не перепакуйте обновления программного обеспечения Майкрософт в пакет установщика Windows. Корпорация Майкрософт выпускает обновления программного обеспечения, такие как пакеты обновления, как самораспаковывание файлов, автоматически выполняющих установку. Эти обновления используют разные установщики, отличные от установщика Windows, для замены защищенных ресурсов Windows и не могут быть преобразованы в пакет установщика Windows. Сведения о развертывании пакетов обновления Windows см. в руководстве по развертыванию пакета обновления в Microsoft TechNet.
  • Не используйте средство перепаковки для преобразования пакета установщика Windows в новый пакет. Установщик Windows добавляет сведения о конфигурации в систему, а также ресурсы приложения. Когда средство перепаковки сравнивает систему до и после установки, перепаковщик неправильно интерпретирует сведения о конфигурации как часть приложения. Обычно это повреждает повторно упакованое приложение. Вместо этого используйте преобразования настроек для изменения существующего пакета установщика Windows или создания нового пакета. Вы можете создавать преобразования настройки с помощью средства Msitran.exe .
  • Не используйте средство перепаковки для консолидации нескольких пакетов установщика Windows в один пакет. Вместо этого можно использовать средство Msistuff.exe для настройки исполняемого файла начальной загрузки Setup.exe для установки пакетов друг за другом.
  • Сделайте пакет установщика Windows, чтобы его можно было легко настроить клиентом. Глобальные переменные, используемые установщиком Windows во время установки, можно задать с помощью общедоступных свойств или преобразований настроек. Предоставьте документацию по использованию этих свойств и практических значений по умолчанию для всех настраиваемых значений. Сведения о получении и настройке свойств см. в разделе "Использование свойств". Пример преобразования настройки см . в примере преобразования преобразования настроек.

Не пытайтесь заменить защищенные ресурсы.

Пакеты установщика Windows не должны пытаться заменить защищенные ресурсы во время установки или обновления. Установщик Windows не удаляет или не заменяет эти ресурсы, так как Windows предотвращает замену основных системных файлов, папок и разделов реестра. Защита этих ресурсов предотвращает сбои приложений и операционной системы.

  • При запуске в Windows Server 2008 или Windows Vista установщик Windows пропускает установку любого файла или раздела реестра, защищенного защитой Windows Resource Protection (WRP), установщик вводит предупреждение в файле журнала и продолжается с остальными версиями установки без ошибки. Дополнительные сведения см. в разделе "Использование установщика Windows" и "Защита ресурсов Windows".
  • WRP — это новое имя для защиты файлов Windows (МПП). WRP защищает разделы и папки реестра, а также основные системные файлы. В Windows Server 2003, Windows XP и Windows 2000, когда установщик Windows столкнулся с файлом, защищенным ВПП, установщик запросит установку файла ВПП. Дополнительные сведения см. в разделе "Использование установщика Windows" и "Защита ресурсов Windows".

Не зависят от некритических ресурсов.

Установка или обновление не должны зависеть от установки некритических ресурсов по следующим причинам.

  • Пользовательские действия могут завершиться ошибкой, если они зависят от компонента, относящегося к компоненту, который пользователь объявляет, а не устанавливает.
  • Пользовательские действия, последовательно выполняемые до действия InstallFinalize , могут завершиться ошибкой, если они зависят от компонента, содержащего сборку, установленную. Установщик Windows не фиксирует сборки в глобальном кэше сборок (GAC), пока действие InstallFinalize не завершится.

Используйте API для получения сведений о конфигурации установщика Windows.

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

  • Функции установки и настройки API установщика Windows описаны в справочнике по функциям установщика.
  • Свойства конфигурации описаны в справочнике по свойствам.
  • Методы и свойства автоматизации описаны в справочнике по интерфейсу автоматизации. Пример скрипта WiLstPrd.vbs подключается к объекту Установщика и перечисляет зарегистрированные продукты и сведения о продукте. Дополнительные сведения см. в разделе "Список продуктов", "Свойства", "Компоненты" и "Компоненты".

Упорядочение установки приложения вокруг компонентов.

Служба установщика Windows устанавливает или удаляет коллекции ресурсов, называемых компонентами. Так как компоненты обычно используются совместно, автор пакета установки должен следовать правилам при указании компонентов компонента или приложения.

  • Соблюдайте правила компонентов при организации приложений в компоненты, чтобы гарантировать, что новые компоненты или новые версии компонентов могут быть установлены и удалены без повреждения других приложений. Вы можете выполнить процедуру, описанную в разделе "Определение компонентов установщика".
  • Установщик отслеживает каждый компонент по соответствующему идентификатору идентификатора компонента, указанному в таблице компонентов. Важно для работы механизма подсчета ссылок установщика Windows правильность GUID идентификатора компонента. Следуйте инструкциям в разделе "Изменение кода компонента".
  • Если пакет должен нарушить правила компонента, помните о возможных последствиях и убедитесь, что установка никогда не устанавливает эти компоненты, где они могут повредить компоненты в системе пользователя. Дополнительные сведения см. в разделе "Что происходит, если правила компонента нарушены?".
  • Помните, как установщик Windows применяет правила управления версиями файлов при замене существующих файлов. Установщик Windows сначала определяет, установлен ли файл ключа компонента перед попыткой установить любой из файлов компонента. Если установщик находит файл с тем же именем, что и файл ключа компонента, установленный в целевом расположении, он сравнивает версию, дату и язык двух ключевых файлов и использует правила управления версиями файлов, чтобы определить, следует ли установить компонент, предоставленный пакетом. Если установщик определяет, что он должен заменить компонент на основе файла ключа, то он использует правила управления версиями файлов для каждого установленного файла, чтобы определить, следует ли заменить файл.

Уменьшите размер больших пакетов установщика Windows.

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

Если вы используете пользовательские действия, следуйте рекомендациям по пользовательским действиям.

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

Если вы используете сборки, следуйте рекомендациям по сборкам

Если пакет использует сборки программного обеспечения, следуйте рекомендациям по добавлению сборок в пакет, обновлению сборок и установке и удалению сборок.

Не отправляйте одновременные установки.

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

Дополнительные сведения об использовании внешнего обработчика пользовательского интерфейса см. в разделе "Мониторинг установки с помощью MsiSetExternalUI". Дополнительные сведения об использовании внешнего обработчика на основе записей см. в статье "Мониторинг установки с помощью MsiSetExternalUIRecord".

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

  • Не используйте одновременные установки для установки или обновления продукта доставки.
  • Одновременные установки не должны совместно использовать компоненты.
  • Административная установка не должна содержать параллельную установку.
  • Интегрированные индикаторы progressBars не должны использоваться с параллельными установками.
  • Ресурсы, которые должны быть объявлены, не должны устанавливаться параллельной установкой.
  • Пакет, выполняющий одновременную установку приложения, также должен удалить параллельное приложение при удалении родительского продукта. Вложенная установка существует в контексте родительского продукта в панель управления надстройки и удаления программ.

Сохраняйте согласованность имен пакетов и кодов пакетов.

Файл .msi можно указать любое имя, которое помогает пользователям определять пакет, но имя не должно быть изменено, не изменяя код продукта.

  • Присвойте файлу .msi понятное имя, позволяющее пользователю определить содержимое пакета установщика Windows.
  • Код продукта является основной идентификацией приложения и должен изменяться всякий раз, когда существует комплексное обновление приложения. Дополнительные сведения см. в разделе ProductCode и изменение кода продукта. Изменение имени файла .msi приложения считается комплексным изменением и всегда требует соответствующего изменения кода продукта для поддержания согласованности.
  • Код пакета является основным идентификатором, используемым установщиком для поиска и проверки правильного пакета для данной установки. У двух неидентных .msi файлов не должно быть одного и того же кода пакета. Если пакет изменяется без изменения кода пакета, установщик может не использовать более новый пакет, если оба пакета по-прежнему доступны установщику. Код пакета хранится в свойстве сводного номера редакции потока сводной информации.
  • Обратите внимание, что буквы в коде продукта и идентификаторах графического кода пакета должны быть в верхнем регистре.

Не используйте таблицы SelfReg и TypeLib.

  • Авторы пакетов установки настоятельно рекомендуется использовать самостоятельную регистрацию и таблицу SelfReg . Вместо этого они должны зарегистрировать модули, создав одну или несколько таблиц в группе таблиц реестра. Многие из преимуществ установщика Windows теряются при самостоятельной регистрации, так как процедуры самостоятельной регистрации, как правило, скрывают критически важные сведения о конфигурации. Список причин предотвращения самостоятельной регистрации см. в таблице SelfReg.
  • Авторы пакетов установки настоятельно рекомендуется использовать таблицу TypeLib . Вместо использования таблицы TypeLib регистрируйте библиотеки типов с помощью таблицы Реестра . Если установка с помощью таблицы TypeLib завершается ошибкой и должна быть откатена, откат может не восстановить компьютер до того же состояния, которое существовало до отката.

Укажите возможность установки без пользовательского интерфейса.

Администраторы часто предпочитают развертывать приложения в корпорации, не требуя взаимодействия с пользователем. Рекомендуется предоставить приложению возможность установки с уровнем пользовательского интерфейса None.

  • Используйте общедоступные свойства для сведений о конфигурации. Администраторы могут предоставить эти сведения в командной строке.
  • Не требуется, чтобы установка зависела от информации, полученной от взаимодействия пользователя с диалоговым окнами. Эта информация недоступна во время автоматической установки.
  • Не перезапускайте компьютер пользователя автоматически во время автоматической установки.
  • Администраторы могут задать уровень пользовательского интерфейса при установке с помощью параметра командной строки "/q". Уровень пользовательского интерфейса также можно задать программным способом с помощью вызова MsiSetInternalUI.

Избегайте использования политики AlwaysInstallElevated.

Если политика AlwaysInstallElevated не задана, приложения, не распределенные администратором, устанавливаются с помощью привилегий пользователя и только управляемые приложения получают повышенные привилегии. Установка этой политики позволяет установщику Windows использовать системные разрешения при установке приложения в системе. Этот метод может открыть компьютер к риску безопасности, так как при установке этой политики пользователь неадминистратор может запускать установки с повышенными привилегиями и безопасными расположениями на компьютере. Рекомендуется использовать другой метод, чем политика AlwaysInstallElevated при установке пакета с повышенными привилегиями для неадминистрированных приложений или исправлений для управляемых приложений, управляемых пользователем.

Включите политику DisableMedia, чтобы ограничить несанкционированную установку.

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

Обеспечение безопасности и доступности исходных файлов исходного пакета для пользователей.

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

  • Используйте цифровые подписи и внешние файлы кабинетов, чтобы гарантировать безопасность используемых установщиком оригиальных источников. Несжатый исходный образ, хранящийся в общедоступном расположении, не является безопасным.
  • Добавьте полный список путей к источнику сети или URL-адреса в пакет установки приложения в свойстве SOURCELIST .
  • Используйте общий ресурс распределенной файловой системы (DFS) для исходного пути.
  • Используйте API установщика Windows для получения и изменения сведений о исходном списке для приложений и исправлений установщика Windows. Дополнительные сведения см. в разделе "Управление источниками установки".
  • Используйте методы и свойства объекта installer, Product Object и Patch Object, чтобы получить и изменить сведения о исходном списке для приложений и исправлений установщика Windows.
  • Придерживайтесь точек, перечисленных в разделе "Запретить исправление требовать доступа к исходным точкам источника установки", чтобы свести к минимуму вероятность того, что исправление потребует доступа к исходным источникам.
  • Сохраните исходные файлы пакета в расположении, которое не является временной папкой системы. Исходные файлы установщика Windows, хранящиеся во временной папке, могут стать недоступными для пользователей.

Включите подробное ведение журнала на компьютере пользователя при устранении неполадок при развертывании.

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

  • Подробное ведение журнала на компьютере пользователя можно включить с помощью параметров командной строки, свойства MsiLogging, политики ведения журнала, msiEnableLog и метода EnableLog.
  • Очень полезный ресурс для интерпретации файлов журнала установщика Windows Wilogutl.exe. Это средство помогает анализировать файлы журналов и отображает предлагаемые решения для ошибок, найденных в файле журнала.
  • Подробный параметр ведения журнала должен использоваться только для устранения неполадок и не должен оставаться в стороне, так как он может оказать негативное влияние на производительность системы и дисковое пространство. Каждый раз, когда вы используете средство "Добавление и удаление программ" в панель управления, создается новый файл.

Удаление оставляет компьютер пользователя в чистом состоянии.

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

  • Если файл, который должен был быть удален с компьютера пользователя, остается установленным после удаления, установщик может не удалить компонент, содержащий файл, по одной или нескольким причинам, описанным в разделе "Удаление странных файлов".
  • Если приложение должно быть зарегистрировано, создайте пакет, чтобы удалить сведения о реестре при удалении приложения. Дополнительные сведения см. в разделе "Добавление или удаление разделов реестра" при установке или удалении компонентов. Если приложение не зарегистрировано, приложение не указано в компоненте "Добавление или удаление программ" в панель управления и не может управляться с помощью установщика Windows.
  • Чтобы скрыть приложение из функции "Добавление или удаление программ" в панель управления и по-прежнему иметь возможность использовать установщик Windows для управления приложением, следуйте рекомендациям, описанным в статье "Добавление и удаление приложения и выход из реестра без трассировки".
  • Пользовательские действия должны быть обусловлены выполнением или не требуется при удалении. При установке и удалении могут потребоваться различные пользовательские действия.
  • Сведения о настройке для конкретного пользователя можно хранить в текстовом файле на компьютере. Это имеет преимущество, что файл можно удалить при удалении приложения, даже если пользователь этой настройки в данный момент не вошел в систему.

Тестовые пакеты для развертывания для каждого пользователя и каждого компьютера.

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

  • Рассмотрите, должно ли приложение быть доступно только определенным пользователям или всем пользователям компьютера во время процесса разработки.
  • Убедитесь, что пакет работает правильно как для каждого пользователя, так и для контекстов установки на компьютер.
  • Сделайте пакет легко настраиваемым и позвольте клиентам решить, следует ли развертывать его на один или отдельный компьютер.

Планирование и проверка стратегии обслуживания перед доставкой приложения.

Перед первым развертыванием приложения следует решить, как вы планируете обслуживать приложение.

Уменьшите зависимость обновлений от исходных источников.

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

Не распределяйте модули слиянием без службы.

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

  • Рассмотрите возможность предоставления необходимых компонентов пользователям в качестве другой установки установщика Windows.

Избегайте установки административных исправлений.

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

  • Размер и задержка загрузки, необходимых для получения обновления пользователями, увеличивается по сравнению с загрузкой исправления. Все обновленные пакеты установщика Windows и исходные файлы должны скачивать, отсчитывать и переустановить их.
  • Пользователи не могут устанавливать приложения по запросу и восстанавливать приложения из обновленной административной установки, пока они не переустановят приложение.
  • Применение исправления к административной установке удаляет цифровую подпись из пакета. Администратор должен уйти в отставку пакета. Дополнительные сведения об использовании цифровых подписей см. в разделе "Цифровые подписи" и установщика Windows.
  • Многие двоичные исправления предназначены для образа RTM приложения и требуют предыдущей версии файла. Локальный экземпляр приложения, установленного из обновленной административной установки, может не работать с другими обновлениями. Многие двоичные приложения исправлений могут завершиться ошибкой.
  • Применение исправления к административной установке обновляет исходные файлы и файл .msi, но не метка сетевого образа с информацией об обновлении. Пользователи не могут определить, какие обновления они получили от административной установки. Это делает невозможным последовательность обновлений, примененных на стороне пользователя, с теми, которые уже применены на стороне административного образа.
  • Исправления, применяемые к административной установке, не удаляются. Это может предотвратить кэширование кода пакета на компьютере пользователя, отличного от кода пакета в административной установке. Если код пакета, кэшированный на компьютере пользователя, отличается от этого в административной установке, переустановите приложение из административной установки, а затем исправьте клиентский компьютер.
  • Если вы решите применить небольшие обновления путем исправления административного образа, следуйте рекомендациям, описанным в разделе: Применение небольших обновлений путем исправления административного образа.

Зарегистрируйте обновления для запуска с повышенными привилегиями.

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

  • Используйте метод SourceListAddSource или функцию MsiSourceListAddSourceEx, чтобы зарегистрировать пакет исправлений как имеющие повышенные привилегии. Следуйте рекомендациям и примерам, приведенным в исправлении управляемых приложений для пользователей.
  • При запуске установщика Windows версии 4.0 в Windows Vista можно также использовать исправление для управления учетными записями пользователей (UAC), чтобы разработчики установок установщика Windows могли определять цифровые исправления, которые могут применяться в будущем пользователями без администратора. Это доступно только при установке пакетов в контексте установки на компьютер (ALLUSERS=1).
  • Убедитесь, что исправление с минимальными привилегиями не было отключено, задав свойство MSIDISABLELUAPATCHING или политику DisableLUAPatching.

Используйте таблицу MsiPatchSequence для последовательности исправлений.

Включите таблицу MsiPatchSequence в пакет и добавьте сведения о последовательности исправлений. Начиная с установщика Windows версии 3.0 установщик может использовать таблицу MsiPatchSequence при установке нескольких исправлений для определения оптимальной последовательности приложений исправлений . Используйте рекомендации, описанные в руководстве по последовательности исправлений в установщике Windows версии 3.0 для определения семейств исправлений.

  • Если это практически, укажите все исправления как принадлежащие одному семейству исправлений. Во многих случаях одно семейство исправлений обеспечивает достаточную гибкость для последовательности исправлений. Сложность разработки увеличивается при использовании нескольких семейств исправлений. Назначьте понятное имя семейству исправлений и назначьте значения последовательности в этом семействе исправлений, которые увеличиваются с течением времени. Следуйте примеру нескольких исправлений, чтобы применить исправления в том порядке, в котором они были выданы.
  • Используйте таблицу PatchSequence в Patchwiz.dll для создания сведений в таблице MsiPatchSequence. Версия PATCHWIZ.DLL, выпущенная с помощью установщика Windows 3.0, может автоматически создавать сведения о последовательности исправлений. Дополнительные сведения о добавлении нового исправления см. в разделе "Создание сведений о последовательности исправлений". Дополнительные сведения о сценариях последовательности исправлений см. в техническом документе: секвенирование исправлений в установщике Windows версии 3.0.

Тщательно проверьте пакет установки.

Проверьте правильность установки, восстановления и удаления пакета установщика Windows. Процесс тестирования можно разделить на следующие части.

  • Тестирование установки— тестирование установки с помощью всех возможных сочетаний функций приложения. Проверьте все типы установки, включая административную установку, установку отката и установку по запросу. Попробуйте все возможные методы установки, включая щелчки по файлу .msi, параметрам командной строки и установке на панели управления. Проверьте, что пакет можно установить пользователями во всех возможных контекстах привилегий. Попробуйте установить пакет после его развертывания всеми возможными методами. Включите ведение журнала установщика Windows для каждого теста и устраните все ошибки, обнаруженные в журнале установщика и журнале событий.
  • Тестирование пользовательского интерфейса— тестирование пакета при установке со всеми возможными уровнями пользовательского интерфейса. Проверьте пакет, установленный без пользовательского интерфейса и со всеми сведениями, предоставленными через пользовательский интерфейс. Убедитесь, что специальные возможности пользовательского интерфейса и что пользовательский интерфейс функционирует должным образом для различных разрешений экрана и размеров шрифтов.
  • Тестирование обслуживания и восстановления. Проверка того, что пакет может обрабатывать исправления и обновления, предоставляемые небольшим обновлением, дополнительным обновлением и основными обновлениями. Перед развертыванием пакета напишите пробное обновление каждого типа и попробуйте применить его к исходному пакету.
  • Тестирование удаления. Убедитесь, что при удалении пакета он не оставляет бесполезных частей себя на компьютере пользователя и что были удалены только сведения, принадлежащие пакету. Перезагрузите тестовый компьютер после удаления пакета и проверьте целостность общих системных средств и других стандартных приложений. Проверьте, что пакет можно удалить пользователями во всех возможных контекстах привилегий. Проверьте все методы, чтобы удалить пакет, щелкните файл .msi, попробуйте использовать параметры командной строки и попробуйте удалить пакет с панели управления. Включите ведение журнала установщика Windows для каждого теста и устраните все ошибки, обнаруженные в журнале установщика и журнале событий.
  • Тестирование функциональных возможностей продукта— убедитесь, что приложение работает должным образом после установки, восстановления или удаления пакета.

Исправьте все ошибки проверки перед развертыванием нового или измененного пакета установки.

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

  • Пакет можно проверить с помощью Orca.exe или Msival2.exe. Оба средства предоставляются в пакете SDK для Windows. Сторонние поставщики также могут включить систему проверки ICE в среду разработки.
  • Можно использовать стандартный набор средств оценки внутренней согласованности — ICES , включенных в файлы CUB, предоставляемые пакетом SDK, или настроить проверку , создав ICE и добавив его в файл CUB.
  • С помощью Evalcom2.dll можно реализовать автоматизацию проверки для пакетов установки и модулей слияния.

Создание безопасной установки.

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

Использование PMSIHANDLE вместо HANDLE

Переменные типа PMSIHANDLE определены в msi.h. Рекомендуется использовать тип PMSIHANDLE, так как установщик закрывает объекты PMSIHANDLE при выходе из области, в то время как приложение должно закрыть объекты MSIHANDLE, вызвав MsiCloseHandle. PMSIHandle предоставляет оператор приведения к MSIHANDLE для совместимости подписей API.

Например, если вы используете следующий код:

MSIHANDLE hRec = MsiCreateRecord(3);

Укажите вместо него следующий код:

PMSIHANDLE hRec = MsiCreateRecord(3);