Ответ 1

Анти-шаблоны развертывания WiX/MSI

В файлах WiX/MSI часто встречается несколько шаблонов развертывания. Ниже приведен черновик некоторых наиболее распространенных.

Перед тем, как приступить к решению проблем, приведу краткое напоминание о том, что сделало MSI полным успехом! (несмотря на свои проблемы).

Этот ответ находится в стадии разработки

Что вы знаете, я ударил максимальный размер для ответа. Я предполагаю, что намек уже достаточно :-). Некоторые разделы нуждаются в уточнении и улучшении.

Если вы обнаружите некоторые из этих проблем, возможно, вы захотите прочитать - все это известные разработчики ненависти и раздражения с помощью установщика Windows/MSI:

• Вы не можете надежно перезаписать файл более низкой версии с вашей последней установкой.
• Вы не можете надежно перезаписать файлы без версии (например, для IIS).
• Файлы таинственно отсутствуют после того, как вы попытаетесь установить обновление MSI.
• Данные стираются во время (основных) сценариев обновления. Примеры включают в себя:
  • В вашем реестре хранится лицензионный ключ.
  • Данные в конфигурационных файлах, таких как config.xml, settings.ini и т.д.
  • Ваши учетные данные для службы, которую вы не используете как LocalSystem.
• Данные не обновляются:
  • Файлы настроек ненадежно обновляются во время установки новыми настройками, которые вы хотите применить.
  • У вас есть проблемы с обновлением настроек в файлах данных, хранящихся на пользователя (или HKCU). Вы обновляете для устанавливающего пользователя, как вы обновляете для других пользователей?
• Вы видите неожиданный самовосстановление для вашей посылки.
• Ваше пользовательское действие заставляет установку взрываться с загадочными ошибками.
• И это важно: вы без необходимости используете настраиваемые действия для вещей, которые уже полностью поддерживаются самим установщиком Windows. Это огромный шаблон развертывания и основная причина сбоев развертывания.
  • Вы устанавливаете Windows Services с помощью пользовательских действий. Это гораздо лучше сделать в самом MSI, используя встроенные конструкции.
  • Вы устанавливаете сборки .NET в GAC с помощью специального действия. Это полностью поддерживается самим установщиком Windows без какой-либо (рискованной) программы.
  • Вы запускаете пользовательские классы инсталлятора сборки .NET. Они должны быть использованы для разработки и тестирования только. Они никогда не должны запускаться как часть развертывания. Скорее ваш MSI должен использовать встроенные конструкции для развертывания и регистрации вашей сборки.
  • Предварительно необходимые настройки и установщики среды выполнения выполняются с помощью настраиваемого действия в вашем собственном MSI. Это должно быть сделано совершенно по-другому. Смотрите раздел 6.
• У вас проблемы с развертыванием общих файлов времени выполнения.
• Установка MSI в режиме без вывода сообщений, по-видимому, приводит к иному состоянию установки, чем установка в интерактивном режиме.

Разделы ниже в произвольном порядке - на данный момент.

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

В ожидании добавления:

• Сложные установки с несколькими экземплярами
  • Относительно общее требование, особенно для сервисных установок
• Деинсталляция не работает для приложения MSI - Ошибка 1722
  • Управление службами: не удается остановить службы перед удалением
  • Удалите центры сертификации: при запуске программы запускаются пакетные файлы/сценарии, которых больше нет на диске
  • Настраиваемые действия: ошибочное условие, поэтому настраиваемое действие выполняется неожиданно. Часто при удалении или во время крупных обновлений.

1. Проблемы самовосстановления

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

• В связи с многогранной природой этой проблемы, я создал отдельный ответ для описания конструктивных конструкций, которых следует избегать, чтобы предотвратить самовосстановление без предупреждения и намерения для вашего приложения: как избежать самовосстановления MSI с моим пакетом WiX/MSI? ,

• Иногда самовосстановление используется как метод для заполнения HKCU настройками приложения или размещения файлов в профиле пользователя каждого пользователя. Как правило, это работает, но, на мой взгляд, не является наилучшей практикой для разработки и развертывания приложений - подробности см. Ниже в разделе 9.

2. Неправильная установка общих, вендорных или Microsoft исполняемых файлов

Хотя это подробно объясняется в приведенной выше ссылке (проблемы самовосстановления), здесь также следует отметить, что одной из наиболее распространенных ошибок в любой настройке является включение "локальных копий" общих файлов времени выполнения, иногда также глобально зарегистрированных в системе, если они являются файлами COM. Инсталляторы для старых приложений VB6 иногда делали это для общих элементов управления, которые им требовались, ломая систему для других приложений.

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

• См. Ссылку на вопросы по самовосстановлению в пункте 1 выше для более подробной информации по этой теме.

3. Неправильная обработка (ваших) общих файлов и данных

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

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

• Чтобы добиться использования одинакового GUID компонента во всех ваших установках, вы должны либо создать модуль слияния для включения в каждую настройку, либо использовать расширенные конструкции в WiX, такие как "включаемые файлы", с жестко закодированными GUID для компонентов, содержащихся в них.

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

4. Ошибки при создании компонента - не следуют передовой практике

Не соблюдайте лучшие рекомендации по созданию компонентов. Компоненты MSI являются основными установочными единицами для файлов и параметров реестра.

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

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

5. Проблемы с обновлением, связанные с перезаписью или сбросом пользовательских данных.

Это не менее чем чрезвычайно распространено. Я ответил на несколько вопросов stackoverflow по этой теме, и он продолжает появляться.

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

• Поскольку обновления в MSI являются сложными, многие стандартизируют основные обновления (самая простая форма обновления). Основное обновление - это, по сути, удаление и переустановка одного и того же продукта (в разных версиях).

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

• Особый случай, о котором следует знать, - это то, что даже если вы правильно поделитесь таким файлом с помощью модуля слияния или включающего файла WiX (чтобы сохранить GUID установочного компонента стабильным) - он, скорее всего, все равно будет удален и переустановлен в результате серьезного обновления, если это только один продукт на коробке, на который он ссылался в то время (счетчик ссылок равен 1).

• После завершения основного обновления выглядит так, как будто файлы данных были перезаписаны или восстановлены, но на самом деле измененные файлы данных были просто удалены, а затем переустановлены в своих "свежих версиях" (скоро будут обновлены с некоторыми возможными исправлениями),

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

• Если вы устанавливаете файл данных для чтения/записи с компонентом, установите его постоянным (или используйте пустой GUID). Правила перезаписи файлов гарантируют, что файл на диске не будет перезаписан во время установки (если вы не сделаете что-то глупое, например, установите REINSTALLMODE в amus для принудительной перезаписи всех файлов - это никогда не должно быть разрешено. Это может привести к понижению рейтинга общих файлов, установленных модулями слияния а также - старая библиотека DLL Hell). Если вы хотите стереть файл и перезаписать его, это также возможно с помощью различных методов, лучшим из которых, вероятно, является использование сопутствующего файла. (более подробная информация будет добавлена позже).
• Wix: служба Windows иногда удаляется при обновлении

6. Ошибочное или ненужное использование пользовательских действий

(Более) -use настраиваемых действий для файлов MSI - огромная тема, и этот раздел стал слишком большим и был разделен на отдельный ответ: почему стоит ограничить использование настраиваемых действий в моих установках WiX/MSI? ,

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

А пользовательские действия по своей природе подвержены ошибкам и являются основной причиной сбоев и ошибок развертывания. Пожалуйста, прочитайте ссылку выше для деталей. Тысячи людей, десятки тысяч людей, даже миллионы людей протестировали эти встроенные конструкции. С какой стати ты делаешь это самостоятельно?

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

7. Неправильное объединение файлов INI.

Можно установить файл INI через таблицу файлов - как и любой другой файл. Это не допускает слияния, если в целевой папке существует существующий INI файл.

• Если вы импортируете записи INI в соответствующие таблицы MSI, вы можете обновить существующий файл INI, используя "объединение" с существующими значениями, а не просто перезаписать файл, "стереть" существующие записи или вообще не обновлять файл.

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

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

• Если вы разрабатываете и используете нестандартный файл INI, рассмотрите возможность придания файлу другого расширения, чем *.INI, чтобы указать на его уникальность и необходимость специальной обработки. По сути, он больше не является файлом INI (формат ключ-значение). Обратное также верно: у вас есть уникальное расширение, и вы можете изменить его на INI, чтобы обрабатывать его как правильный файл INI, если содержимое файла представляет собой пары ключ-значение.

8. Ошибочно использовать саморегистрацию для COM файлов

Или установите их регистрацию через стол реестра. Используйте соответствующие рекламные таблицы COM. Есть много причин, как объяснено здесь: Самостоятельная регистрация считается вредной.

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

• Чтобы иметь личное мнение: когда я вижу, что на настройки сети влияет саморегистрация, я немедленно хочу, чтобы программное обеспечение было полностью отклонено для использования. Вот как серьезно делать что-то "хакерское" в стандартизированной операции, такой как саморегистрация. Разумный вопрос, который нужно задать, это "что еще им нужно сделать, учитывая эту хитрую регистрацию COM". Просто не стоит полагаться на нестандартные, хакерские вещи.

9. Чрезмерное использование файла -use r и развертывание реестра.

ОБНОВЛЕНИЕ: новый ответ, относящийся к этой теме: Создайте папку и файл в профиле текущего пользователя из профиля администратора.

Этот раздел стал слишком большим и был разделен на отдельный ответ: почему при использовании MSI рекомендуется ограничить развертывание файлов профилем пользователя или HKCU?

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

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

10. Автоматическая установка не завершена или не завершена

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

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

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

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

• Никогда не показывайте диалоги из ваших пользовательских действий в InstallExecuteSequence. Это может привести к полному сбою автоматической установки, поскольку эти диалоговые окна не будут автоматически подчиняться настройке UILevel текущей установки. Когда установка запускается в автоматическом режиме через системы развертывания, может появиться модальное диалоговое окно, блокирующее завершение установки, и, конечно, пользователь не сможет закрыть диалоговое окно. Вы можете использовать свойство UILevel, чтобы определить, выполняется ли установка в режиме без вывода сообщений, а затем подавить отображение диалогового окна, но показ диалога, подобного этому, является просто неправильным дизайном.

11. Вы пытаетесь принудительно перезаписать файлы с помощью установщика MSI

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

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

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

• Поведение файла при перезаписи может быть слегка изменено пользовательскими настройками для свойства REINSTALLMODE, установленного на уровне командной строки msiexec.exe (перезапись старых версий, перезапись одинаковых версий, перезапись любой версии и т.д.). Установка свойства REINSTALLMODE изменяет логику замены файлов для всех файлов во всей установке, включая файлы, развернутые с помощью модулей слияния, которые могут предназначаться для файлов в общих папках. Следовательно, вы можете понизить версию общих файлов и компонентов - именно то, о чем был "DLL Hell".

• Тем не менее, важно понимать "правила перезаписи файлов" и то, как на них могут влиять параметры, но это параметр, который применяется ко всем файлам во всей установке. Есть также несколько "хаков" для перезаписи только определенных файлов.

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

• Этот раздел еще не закончен.

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

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

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

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

• Избавьте себя от лишних хлопот и спроектируйте службу так, чтобы она работала как LocalSystem ( или, может быть, лучше - другая учетная запись, предназначенная для использования службы) - быстро прочитайте этот связанный контент и поговорите с командой разработчиков о возможностях. Вот еще один пост это может стоить фальсификации: безопасно ли запускать пул под NT AUTHORITY\NETWORK SERVICE?).

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

• ОБНОВЛЕНИЕ: также следует упомянуть более новую концепцию управляемых учетных записей служб. Пошаговое руководство (также см. Раздел в этом ответе об управляемых и групповых учетных записях служб).

13. Ваше приложение требует широких, пользовательских привилегий NT

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

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

Почти все эти привилегии опасно разбазаривать.

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

• По моему опыту, запрашиваемые привилегии имеют тенденцию вращаться вокруг " прав пользователя входа в систему ". SeNetworkLogonRight (доступ к компьютеру из сети), SeInteractiveLogonRight (вход в систему локально), SeBatchLogonRight (вход в систему как пакетное задание) и большой: SeServiceLogonRight (вход в систему как служба).

• Некоторые привилегии NT, такие как SeAssignPrimaryTokenPrivilege, SeBackupPrivilege, SeDebugPrivilege, SeIncreaseQuotaPrivilege, SeTchPrivilege (действуют как часть операционной системы) и некоторые другие, никогда не должны применяться никаким вменяемым пакетом.

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

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

14. Вы применяете много пользовательских разрешений для дисков и реестра

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

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

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

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

• Я часто сталкивался с повторяющимися проблемами самовосстановления, вызванными ошибочными разрешениями, примененными к диску или реестру: как избежать запуска самовосстановления MSI с помощью пакета WiX/MSI? (раздел 5).

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

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

15. Ваш лицензионный ключ в реестре сбрасывается при обновлении

Очень распространенный дизайн - запись лицензионного ключа в реестр с использованием компонента MSI. Это может быть HKCU или чаще HKLM - чтобы сделать его общей лицензией для всех пользователей на одном компьютере.

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

Я редко, если вообще когда-либо, рекомендую чтение/запись пользовательских действий. Они подвержены ошибкам и могут быть сложными для получения правильных результатов - и большинство людей никогда не реализуют правильный откат (если происходит сбой установки и требуется откат). Однако у вас также есть больше возможностей для проверки "текущего состояния" системы с помощью настраиваемого действия, и вы можете настроить свое настраиваемое действие так, чтобы оно всегда выполнялось, даже во время последовательности исправлений, и вы можете сделать так, чтобы оно выполняло разные действия во время разных последовательностей, если вам нужно. В большинстве случаев могут возникнуть проблемы с выполнением пользовательских действий, когда они не предназначены - например, во время установки исправления. Мало кто помнит, чтобы обусловить свои пользовательские действия NOT PATCH (чтобы предотвратить запуск во время исправления).

Несмотря на все это, я мог бы просто использовать пользовательское действие для записи лицензионного ключа в HKLM во время установки, если я получил указание написать лицензию во время установки. Тем не менее, и это важно, я бы предпочел полностью исключить проблему лицензирования из установки по многим причинам, описанным здесь: Установщик с онлайн-регистрацией для приложения Windows (рекомендуется прочитать - есть много причин, чтобы не выдавать лицензию) вашей настройки).

16. Нежелательные жестко закодированные GUID

Некоторые GUID могут быть жестко запрограммированы в вашем исходном файле WiX (или другом инструменте создания MSI). Например, GUID компонентов - они должны оставаться стабильными для каждого компонента, если только вы не измените место установки. Обоснование этого объясняется здесь: Изменить GUID моего компонента в wix?

Тем не менее, не стоит жестко кодировать код пакета. Код пакета MSI всегда должен генерироваться автоматически для каждой сборки. Он просто должен быть уникальным. Более подробно; идея GUID пакета состоит в том, что он должен быть уникальным для каждого скомпилированного файла MSI. Это просто, чтобы однозначно идентифицировать файл. Установщик Windows рассматривает два разных файла MSI с одинаковым GUID пакета как один и тот же файл по определению. Все виды проблем X файлов в результате. Соответственно, GUID пакета всегда должен генерироваться автоматически, поскольку он просто должен быть уникальным.

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

17. Ошибочное включение конфиденциальных данных

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

По сути, совет заключается в том, чтобы дать вашим файлам повторный доступ к жестко закодированным грехам dev-box. Как проверить? Мне это не нравится, открываю MSI с Orca - и просто просматриваю столы. Наиболее уязвимыми таблицами, вероятно, являются: Registry, Property, IniFile, возможно Directory, и, если вы используете графический интерфейс MSI: all tables relating to GUI. Любые сценарии (таблица CustomAction или Binary таблица - последняя требует от вас потоковой передачи любых сценариев или проверки их в местах их расположения).