Как заставить WIX не удалять определенные файлы при выполнении серьезного обновления

Question

Как заставить WIX не удалять определенные файлы при выполнении серьезного обновления

У меня есть два компонента, в которых один компонент simple.exe и другой компонент имеет sample.dll в одном MSI. Если я установлю MSI оба simple.exe а также sample.dll установит и в программных файлах в какой-то папке он имеет два один .exe а также .dll, Если я сделаю серьезное обновление до всего MSI, он заменит папку, созданную в файлах программы, новой. Так как заставить wix не заменять .exe если я изменю / предоставлю обновление для .dll файл и наоборот. И при предоставлении обновления .dll Я буду регистрировать и отменять регистрацию ключей, используя некоторые .bat файл. Пожалуйста, помогите мне решить, мне нужно условное серьезное обновление, которое заменит определенные файлы при их изменении.

Пожалуйста, найдите ниже код:

product.wxs

<?xml version="1.0" encoding="UTF-8"?>
<?define ProductVersion = "0.0.4"?>
<?define ProductUpgradeCode = "d3170abf-b41c-4274-a3a0-85576052f35c"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="saranSample" Language="1033" Version="$(var.ProductVersion)" Manufacturer="example" UpgradeCode="$(var.ProductUpgradeCode)">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />

    <MajorUpgrade DowngradeErrorMessage="A newer version of product is already installed." AllowSameVersionUpgrades="no" AllowDowngrades="no" />
    <MediaTemplate EmbedCab="yes" />

<Upgrade Id="$(var.ProductUpgradeCode)">
  <UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes" Property="NEWERVERSIONDETECTED"/>
  <UpgradeVersion Minimum="0.0.0" Maximum="$(var.ProductVersion)" IncludeMinimum="yes" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED"/>
</Upgrade>
<InstallExecuteSequence>
  <Custom Action="Filecleaner" After="InstallFinalize"></Custom>
</InstallExecuteSequence>
<Condition Message="A newer version of this software is already installed.">NOT NEWERVERSIONDETECTED</Condition>

    <Directory Id="TARGETDIR" Name="SourceDir">
        <Directory Id="ProgramFilesFolder">
    <Directory Id="INSTALLFOLDER" Name="saranSample_$(var.ProductVersion)">
      <Component Id="exeFiles" Guid="12345678-1234-1234-1234-222222222222">
        <File Id="exe" Source="$(sys.CURRENTDIR)npp.7.5.7.Installer.exe" KeyPath="yes"/>
      </Component>
      <Component Id="dllFiles" Guid="12345678-1234-1234-1234-222222222223">
        <File Id="dll" Source="$(sys.CURRENTDIR)saran.dll" KeyPath="yes"/>
      </Component>
    </Directory>
        </Directory>
    </Directory>

<Feature Id="ProductFeature" Title="saranSample" Level="1">
  <ComponentRef Id="exeFiles"/>
  <ComponentRef Id="dllFiles"/>
</Feature>

2

wix windows-installer wix3 preserve major-upgrade

Источник

user9354989 19 июл '18 в 04:04

2 ответа

Решение

Несколько вещей:

Почему у вас есть элемент MajorUpgrade, а также элементы Upgrade? Элемент MajorUpgrade должен быть всем, что вам нужно, так что это сбивает с толку.
Как и в документации MajorUpgrade, последовательность обновления по умолчанию - afterInstallValidate. Это "раннее" обновление, которое эффективно удаляет все старые продукты перед установкой новой версии. Вот почему файлы удаляются (путем удаления), а затем устанавливаются снова.
Похоже, что ваше расписание MajorUpgrade должно быть после InstallExecute. Это устанавливает новые файлы продукта поверх старых файлов, используя правила перезаписи версии файла. Если версии двоичных файлов не изменились, они не будут заменены. Этот тип обновления также требует соблюдения правил компонента:

http://robmensching.com/blog/posts/2003/10/18/component-rules-101/

https://docs.microsoft.com/en-us/windows/desktop/msi/what-happens-if-the-component-rules-are-broken

Кроме того, вы упоминаете регистрацию, используя bat-файл, и это не обязательно. WiX имеет инструмент Heat для извлечения регистрации при сборке, т.е.

0

Источник

user3261150 19 июл '18 в 18:11

Другие вопросы по тегам wix windows-installer wix3 preserve major-upgrade

user129130 20 июл '18 в 00:16 2018-07-20 00:16 · Accepted Answer · 2018-07-20 00:16

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

Один файл на компонент: убедитесь, что вы используете один компонент для каждого устанавливаемого файла. Я делаю это для всех типов файлов, но вы должны для двоичных файлов (DLL и EXE). Это сделано для того, чтобы установщик работал правильно и соответствовал правилам компонентов MSI (упомянутым Филом). Я вижу, у вас есть компоненты EXE-файлов и один для DLL-файлов. Создайте новые компоненты для каждого двоичного файла, который вы добавляете в свои настройки, и установите двоичный файл в качестве ключевого пути для компонента.

Выборочное обновление файлов: если вы хотите сохранить старые версии файлов на диске при выборочной установке нового пакета с файлами более высоких версий, то я не знаю способа сделать это, если не попытаться установить файлы только для чтения (что я никогда не пробовал - не уверен, что будет честно). Вы также можете установить пустой GUID компонента (такой GUID также известен как "Little Bobby Void-GUID ", просто проверьте этот очень официальный источник) - это установит один или несколько файлов и никогда не трогает и не перезаписывает их снова. Также есть флаг компонента, который можно установить, чтобы никогда не перезаписывать, если существует путь к ключу компонента (я обычно комбинирую это с установка постоянного компонента). Также возможно подделать номер версии для файла путем последующей обработки созданного MSI. Некоторые сторонние инструменты, такие как Installshield и Advanced Installer, предоставляют графический интерфейс для этого перед компиляцией.

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

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

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

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

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

Кроме того, вы можете установить постоянные файлы настроек в MSI. Тогда они никогда не будут удалены, но, вероятно, никогда не будут обновлены и никогда не будут удалены, если вы не создадите для этого свои собственные конструкции.

Переменные пути: ли$(sys.CURRENTDIR)хорошо работать для вас? Мне нравится определять мою собственную переменную пути, которую я могу с легкостью перенаправить в любую папку, которую я хочу с легкостью:

<?define SourceFiles= "C:\Projects\MySetup\Releases\1.0.0\"?>

<...>

<Icon Id="Icon.exe" SourceFile="$(var.SourceFiles)\MyApp.exe" />

Некоторые ссылки:

Алексей Шевчук: От MSI до WiX(контент устарел, но хорош)