Как выразить файловую зависимость с помощью WiX - PullRequest
0 голосов
/ 12 декабря 2018

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

Теперь мне пришлось разделить одну из DLL на 2 и добавить новый компонент во время выполнения, устанавливая новую DLL.Эта новая DLL связана с другими библиотеками среды выполнения.Теперь предположим следующий сценарий:

  • установить старый пакет с модулем слияния для среды выполнения без новой DLL
  • установить новый другой пакет с более новой версией модуля слияния длявремя выполнения.Теперь в системе есть 2 пакета
  • удалите новый пакет снова

Теперь старый пакет сломан, потому что:

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

Так что мой вопрос:

  • Есть ли способ явно указатьв коде WiX этот файл A зависит от файла B, так что он остается в системе до тех пор, пока не будут удалены все ссылки?
  • или есть способ явно понизить рейтинг зависимостей таким образом, чтобы зависимость больше не существовала?
  • Я делаю что-то в корне не так?

То, что я пробовал на чистой машине, так это следовал советам Стейна Осмуля:

<Component Id='OldLibsNowDependingOnNewLib' Guid='C8DCD2AB-CBE5-4853-9B25-9D6FE1F678DD'>
  <File Id='LibOne' Name='LibOne.dll' Source='$(var.SourceDir)/LibOne.dll' />
  <File Id='LibTwo' Name='LibTwo.dll' Source='$(var.SourceDir)/LibTwo.dll' />
</Component>
<Component Id='NewLibComponent' Guid='CD2DB93D-1952-4788-A537-CE5FFDE5F0C8' Shared='yes'>
  <File Id='LibNew' Name='LibNew.dll' Source='$(var.SourceDir)/LibNew.dll' />
</Component>

Однакок сожалению, это не меняет поведение.

1 Ответ

0 голосов
/ 13 декабря 2018

ОБНОВЛЕНИЕ : Снова просматривая SDK, я вижу флаг msidbComponentAttributesShared для компонентов.Это выглядит многообещающе для проблемы, которую вы описываете.Пожалуйста, попробуйте включить этот флаг и перекомпилировать версию 2 вашей установки (если она не активна).

Включить Общий флаг для рассматриваемого компонента (последняя часть):

<Component Feature="Product" Shared="yes">

Кажется, это для поддержки патчей, но, возможно, это будет работать и для вашего случая. Из MSI SDK :

"If a component is marked with this attribute value in at least one package installed on the system, the installer treats the component as marked in all packages. If a package that shares the marked component is uninstalled, Windows Installer 4.5 can continue to share the highest version of the component on the system, even if that highest version was installed by the package that is being uninstalled."


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


Краткий ответ : Используйте Burn (установщик цепи) WiX для последовательной установки программы установки и новогоотдельная настройка во время выполнения, которая может обрабатываться независимо от версии установки вашего приложения.


Предварительная настройка : Интересный случай.Вот почему мне нравится разбивать предварительные условия на собственный пакет MSI и развертывать его через Burn Bundle Bootstrapper.Burn - это WiX bootstrapper / downloader / chainer - по сути, способ запустить несколько установок последовательно - в нескольких различных форматах, таких как MSI, EXE, MSU, MSP.При этом - помещая среду выполнения в свой собственный MSI - нет никаких путаниц, и вы получаете хорошую развязку ваших файлов времени выполнения и конкретных приложений.Другими словами: вы можете обновлять файлы времени выполнения самостоятельно - с помощью собственного MSI.Файлы даже будут иметь reference count из 1, что означает, что вы можете легко удалить их все (не если вы устанавливаете их через модуль слияния, который также может быть включен в другие пакеты -подробнее ниже).

Модули слияния - полустатическое связывание? : Странным образом модули слияния являются своего рода полустатическими связями.Весь модуль слияния является версией - бинарным пакетом (например, COM), но его поведение при установке является одним из «выигрывает более высокая версия».Следовательно, один более новый MSI с новейшим модулем слияния будет обновлять общие файлы для всех приложений, которые их используют.После этого деинсталляция сделает то, что вы видите: сохраните файлы, которые были изначально установлены в более старых установках.

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

  • Постоянный компонент : Вы можете установить компонент размещения для нового файла в системе как постоянный.Это очень легко, но также довольно глупо и не всегда очень желательно.Удаление не приведет к удалению файла вообще.
  • Предварительное условие : это мой любимый вариант, упомянутый выше.Вы компилируете обязательную установку MSI, которая устанавливает компоненты среды выполнения.Этот MSI может доставлять обновления самому себе, не затрагивая основное приложение.Это основное пособие, которое я получаю после: Cohesion & Coupling.
    • Модули слияния : я бы вообще отказался от модулей слияния, но обычно объединение одного и того же модуля слияния в предварительную настройку - если у вас уже есть модуль слияния,
      • В большинстве случаев слияние модуля слияния - это нормально, так как вы затем устанавливаете предварительную версию, а затем можете устанавливать и удалять версии приложения по своему усмотрению, не затрагивая среду выполнения, поскольку другой продукт (предварительная версия MSI) установил среду выполнения - и этоНастройка должна остаться позади и не должна быть удалена.
      • Если модуль объединения не работает и приводит к конфликту, который у вас уже был, возможно, попробуйте объединить с msidbComponentAttributesShared «решением», упомянутым выше.Пока не проверено мной.Всегда рискованно предлагать подобные вещи, но это «лучшее усилие».
    • Включаемые файлы WiX : Я предпочитаю использовать включаемые файлы WiX, что позволяет мне извлекать новые файлы без повторной авторизации всего модуля слияния в двоичном формате (например, включаемые файлы C ++в отличие от повторного использования двоичного кода в стиле COM модуля слияния).
  • Side-By-Side : Многие люди предпочитают устанавливать предварительные требования на сторонетаким образом, чтобы несколько версий среды выполнения могли сосуществовать.Это может включать или не включать GAC.Переключение версий во время выполнения было бы задачей манифеста манифеста.Обычно несколько запутанно, но выполнимо.Вы можете использовать как модули слияния, так и отдельные файлы MSI для развертывания таких сред выполнения - как описано выше.Я бы определенно использовал обязательный MSI.

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

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

бессмысленные параметры : параметры, которые не имеют смысла, будут включать новый файлв обе версии настройки.Нет выгоды, много накладных расходов.Некоторые люди любят копировать новые файлы локально в основную папку установки.Не работает, так как файлы, с которыми он связан, скорее всего, находятся в другом месте (место выполнения). Статическое связывание в этом случае не было бы уместно, я думаю.Я думаю, только в крайнем случае, чтобы решить живую проблему.Установка флага SharedDllRefCounter не повлияет на подсчет ссылок MSI, он равен для устаревшего подсчета ссылок (не-MSI), хотя его ручная настройка является экстренным «решением». В крайнем случае , с которыми сталкиваются люди, обычно это отказ от установки во время выполнения и установка всего в одну папку установки.Затем вы должны всегда перекомпилировать все для каждого выпуска - чего вы хотите избежать?


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

...