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

StackOverflow https://stackoverflow.com/questions/660531

Вопрос

У меня есть сборка MSI с использованием WiX версии 3.

Все предыдущие установщики для продукта, который мы развертываем, отлично работали с указанной конфигурацией (то есть:если предыдущая версия существует, удалите, затем установите новую версию) - однако новая MSIS, которую мы создаем, не устанавливает все файлы при запуске по пути "сначала удалить".

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

Мы попробовали запустить с включенным подробным и дополнительным ведением журнала (/l*vx) однако все, что мы можем увидеть, это то, что файлы не регистрируются и затем не устанавливаются.

Есть какие-нибудь мысли или предложения?Это загоняет нас на стену.

Это было полезно?

Решение 2

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

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

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

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

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

(Кроме того, более подробную информацию об этом свойстве можно найти здесь: MSDN:ПЕРЕУСТАНОВИТЕ Свойство MODE

Другие советы

На основе пользовательской последовательности действий по умолчанию установщик Windows определяет, какие файлы необходимо установить / перезаписать перед удалением любых существующих версий программного обеспечения.Установщик Windows использует значение свойства REINSTALLMODE, чтобы указать ему, как принимать решения о том, когда перезаписывать файлы.Если REINSTALLMODE содержит "o", то он будет устанавливать только файлы, версия которых отличается или файл еще не существует;неверсионные файлы будут установлены только в том случае, если дата изменения файла <= дата создания (т.е.файл не изменен).Если режим ПЕРЕУСТАНОВКИ содержит "a", он всегда будет устанавливать файл, независимо от какой-либо версии или информации о дате, прикрепленной к существующим файлам.

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

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

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

Что делает ваш <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 определенно содержал файл, лучшим доказательством чего является то, что файл был бы помещен при восстановлении.Кроме того, взрыв 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}'.Проект был перенесен, в результате чего количество СОТРУДНИКОВ увеличилось с 444 до 30.

Включение wixscript имеет следующее, 

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

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

Решение состояло в том, чтобы немного изменить сценарий сборки этой библиотеки dll, чтобы установить версию сборки на '10.0.1.{git rev-list --count HEAD}', предположительно обрабатываемый как версия с более высоким номером.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top