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

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

прежде чем идти в проблемы, с другой стороны вот краткое напоминание о том, что сделало MSI общим успехом! (несмотря на проблемы).

этот ответ-работа в прогресс!--14-->

что вы знаете, я ударил максимальный размер для ответа. Думаю, этого намека уже достаточно: -). Хотя некоторые разделы нуждаются в уточнении и доработке.

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

• вы не может надежно перезаписать более низкая версия файл с новейшей настройкой.
• вы невозможно надежно перезаписать файлы без версий (например для IIS).
• файлы таинственным образом отсутствует после попытки установить обновление MSI.
• данные уничтожаются во время (основных) сценариев обновления. Примеры включают:
  • код в реестре хранится лицензионный ключ.
  • данные конфигурационные файлы такие как конфиг.XML-файле, настройки.ini, etc...
  • код учетные данные услуги для службы, которую вы не запускаете как LocalSystem.
• данные не обновляются:
  • файлы настроек не обновляются надежно во время установки с новыми настройками, которые вы хотите применить.
  • у вас есть проблемы с обновлением настроек в файлах данных, хранящихся на пользователя (или HKCU). Обновление для устанавливающего пользователя, как вы обновляете для других пользователей?
• видишь саморемонтный удар неожиданно для вашего пакета.
• код настраиваемое действие делает установку бомбы с таинственными ошибками.
• и это большой вы излишне использовать пользовательские действия для вещей, которые уже полностью поддерживаются самим установщиком Windows. это огромное развертывание anti-pattern, и основная причина сбоев развертывания.
  • установки служб Windows через пользовательские действия. Это гораздо лучше сделать в самой MSI, используя встроенные конструкции.
  • вы устанавливаете сборки .NET в GAC через пользовательское действие. Это полностью поддерживается самим установщиком Windows без строки (рискованного) кода.
  • вы запускаете пользовательские классы установщика сборки .NET. Они должны быть использованы для разработки и тестирования только. Они должны!--10-->никогда в рамках развертывания. Вместо этого MSI должна использовать встроенные конструкции для развертывания и регистрации сборки.
  • запустить условием установки и выполнения монтажники через дополнительное действие в свой МСИ. Это должно быть сделано совершенно иначе. См.раздел 6.
• у вас проблемы с развертыванием динамические файлы.
• установка вашего MSI, по-видимому, приводит к другому состоянию установки, чем при интерактивном запуске установки.

разделы ниже не находятся в определенном порядке вообще - на данный момент.

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

до того:

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

1. проблемы с Саморемонтом

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

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

• иногда self-repair используется как метод для заполнения HKCU с настройками приложения, или поместить файлы в профиле пользователя каждого пользователя. Это обычно работает, но, на мой взгляд, не лучшая практика для разработки и развертывания приложений - см. Более подробную информацию ниже в разделе 9.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

по существу пользовательские действия часто не нужны из-за встроенной поддержки в MSI для достижения того же эффекта или наличия готовых решений в бесплатных фреймворках, таких как WiX или коммерческие инструменты, такие как Advanced InstallShield или 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. чрезмерное использование каждого пользователя файла и развертывания реестра

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

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

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

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

10. Тихая установка не завершается или является неполной

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

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

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

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

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

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

MSI имеет некоторые довольно сложный "правила управления версиями файлов" предназначен для минимизации влияния "DLL ад". Они, как правило, вызывают файлы не перезаписываются по назначению-классическая проблема 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 self-repair с моим пакетом WiX / MSI? (раздел 5).

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

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

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

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

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

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

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

16. Нежелательные Жестко Закодированные GUIDs

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

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

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

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

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

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