MSI не устанавливает все файлы при запуске RemovePreviousVersion - PullRequest
Новая
       54

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

14 голосов
/ 19 марта 2009

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

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

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

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

Есть мысли или предложения? Это ведет нас к стене.

Ответы [ 4 ]

18 голосов
/ 14 апреля 2009

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

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

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

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

5 голосов
/ 19 марта 2009

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

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

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

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

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

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

3 голосов
/ 19 марта 2009

Как выглядит ваш <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>
1 голос
/ 23 августа 2018

Я знаю, что это более старая тема, но я столкнулся с аналогичной проблемой, которая не была охвачена решениями. В моем случае у меня была 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}». Проект был перенесен, в результате чего количество HEAD изменилось с 444 до 30.

Включает wixscript, 

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

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

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

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

...