MSI не устанавливает все файлы при запуске RemovePreviousVersion

На основе последовательности настраиваемых действий по умолчанию установщик Windows определяет, какие файлы необходимо установить / перезаписать перед удалением любых существующих версий программного обеспечения. Установщик Windows использует значение свойства REINSTALLMODE, чтобы сообщить ему, как принимать решения о том, когда перезаписывать файлы. Если REINSTALLMODE содержит «o», то он установит только те файлы, версия которых отличается или файл еще не существует; Файлы без поддержки версий будут установлены только в том случае, если Дата изменения файла ‹= Дата создания (т. е. файл не изменен). Если REINSTALLMODE содержит «a», он всегда будет устанавливать файл, независимо от любой информации о версии или дате, прикрепленной к существующим файлам.

Скорее всего, в вашем сценарии происходит следующее:

1. Установщик Windows определяет, какие файлы устанавливать. Он решает, что некоторые файлы не нужно устанавливать (возможно, потому, что они уже существуют и имеют ту же или более новую версию, что и файлы в MSI).
2. Удаляется предыдущая версия программного обеспечения, включая файлы, которые установщик Windows определил, в установке не требуется.
3. Установщик Windows устанавливает файлы для новой установки, но не устанавливает файлы, которые, по его мнению, не нуждаются в установке.

Конечным результатом является то, что после обновления программного обеспечения отсутствует куча файлов. Установка REINSTALLMODE = amus вместо omus, скорее всего, решит вашу проблему, но вы должны убедиться, что знаете, как это повлияет на остальную часть вашей установки. Если есть какие-либо файлы, которые вы не хотите перезаписывать, вам нужно будет пометить эти компоненты как «Никогда не перезаписывать».

Хорошо, поговорим с кем-то еще, и я помог мне найти решение проблемы.

Мы добавили свойство REINSTALLMODE и установили его на amus. Что это значит?

По умолчанию для свойства установлено значение omus, что означает: переустановить, если файл отсутствует или старше, перезаписать реестр для кустов компьютеров и пользователей, переустановить ярлыки. Изменение этого параметра на amus в основном означает: переустановите все файлы.

Итак, я не уверен на 100%, в чем была причина - я подозреваю, что могли быть странные блокировки или что-то в этом роде, но установка на amus не приводит к каким-либо побочным эффектам, поэтому мы будем придерживаться этого.

Спасибо за предложения.

(Кроме того, более подробную информацию об этом свойстве можно найти здесь: Свойство MSDN: REINSTALLMODE

Как выглядит ваш <RemoveExistingProducts After=""> шаг? Возможно, программа removeexisting запущена после установки и удаляет все файлы, которые были одинаковыми в предыдущей и текущей версиях.

У меня установщик установлен на <RemoveExistingProducts After="InstallInitialize">, чтобы убедиться, что это сделано, прежде всего. Не знаю, правильно это или нет, но вроде работает.

    <Upgrade Id="$(var.UpgradeCode)">
        <!--Upgrade code found at http://www.nichesoftware.co.nz/blog/200809/upgradable-msi-installations-with-wix -->
        <!-- Detect any newer version of this product-->
        <UpgradeVersion Minimum="$(var.version)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />

        <!-- Detect and remove any older version of this product-->
        <UpgradeVersion Maximum="$(var.version)" IncludeMaximum="yes" OnlyDetect="no" Language="1033" Property="OLDPRODUCTFOUND" />
    </Upgrade>
    <CustomAction Id="PreventDowngrading" Error="Newer version already installed"></CustomAction>
    <InstallExecuteSequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
        <RemoveExistingProducts After="InstallInitialize" />
    </InstallExecuteSequence>
    <InstallUISequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

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

msiexec /i myproduct.msi /l*vx install2.log

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

Это не помогло:

msiexec /i myproduct.msi REINSTALL=ALL REINSTALLMODE=amus /l*vx install3.log

Я создаю MSI с Wix и использую этот скрипт много лет. Совсем недавно мы установили скрипт на полное удаление старого каталога в нашей версии 5.3. Это работало до обновлений 5.2 -> 5.3 и 5.3 -> 5.4. Но в версии 5.5 все библиотеки DLL были перестроены с использованием новых версий библиотек DLL. Проекты DLL размещались на GitHub. Сценарий сборки для этой конкретной DLL был установлен как версия сборки '10 .0.0. {Git rev-list --count HEAD} '. Проект был перемещен, в результате чего количество HEAD увеличилось с 444 до 30.

В wixscript есть это,

define ProductGuid = "{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}"

поэтому мы обновляем руководство по продукту (а не руководство по обновлению продукта) в каждом выпуске.

Чтобы исправить это, нужно было немного изменить сценарий сборки этой библиотеки, чтобы установить версию сборки '10 .0. 1. {Git rev-list --count HEAD} ', что предположительно рассматривается как более высокая пронумерованная версия.

Почему это сработало, я не могу объяснить.