Как опустить компонент, когда мы пытаемся собрать.msi с помощью wix

У меня есть .exe файл и .dll (IE дополнение) в одном MSI. Когда пользователь устанавливает его в первый раз, оба файла будут установлены, и в программных файлах в указанной папке он создаст .exe а также .dll, Теперь я хочу предоставить обновление для .dll (IE дополнение) только. Когда я сгенерирую MSI снова с обновленным файлом .dll как опустить .exe файл не загружать в MSI. Так как .exe Размер файла очень большой, пользователю потребуется много времени для обновления MSI. Есть ли способ опустить .exe компонент в недавно сгенерированном MSI или, пожалуйста, предложите мне другие способы достижения этого.

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>
Источник

1 ответ

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

Тем не менее, имейте в виду, что исправление MSI очень сложно и, по сути, требует безупречных пакетов со 100% соответствием правилам компонентов MSI - что на самом деле редко встречается в реальном мире (у Роба Меншинга 101 по правилам компонентов - он WiX) создатель). Чтобы преуспеть в этом, вам нужно быть очень осторожным, как вы делаете вещи в MSI, как в отношении дизайна компонентов, пользовательских действий (сложные условия, должны ли они выполняться во время исправления? Etc...), так и других вещей.

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

Попытка ответа: Итак, попытка ответа состоит в том, что вы действительно можете предоставить меньший пакет исправлений для дистрибутива, основанный на работающем обновлении MSI, но это не пикник, чтобы заставить его работать должным образом, и, вероятно, не рекомендуется, если у вас ограниченный опыт MSI и ограниченное время сосредоточиться на изучении тонкостей технологии. I guess you have to ask yourself how important this small distribution package really is in a world of broadband internet and fast computer I/O?

Если бы я был вынужден реализовать это исправление, я бы использовал небольшое обновление, и я бы установил, чтобы исправление не использовало исправление на уровне битов. Это означает, что включены только целые файлы, а не двоичный разностный код предыдущего и нового двоичного файла, что я считаю ненужной сложностью и риском. Идея состоит в том, чтобы сделать патч более надежным (Why? What happens with bit-level patching when the file in question is signed? Frankly I have no idea).

Технические детали: Время исповеди: несмотря на все мои годы работы с MSI, я никогда не использовал WiX для создания патчей. Я использовал Installshield и Wise для создания патчей, и последний работал для меня (Wise). Для того, чтобы использовать WiX для создания патчей, ресурс, с которого я знаю, начать с этого:

Некоторые избранные ссылки:

Ссылки Microsoft:

Дополнительные ссылки:

Источник
Другие вопросы по тегам