Wix main upgrade не устанавливает все файлы

У меня очень простой проект WiX (версия 3.7), который устанавливает somes файлы (.NET-версия 6.0.0.0). Я готов выпустить новую версию 6.0.1.0 с использованием функций MajorUpgrade в WiX.

Я сохраняю UpgradeCode одинаковым в элементе Product и меняю версию с 6.0.0.0 на 6.0.1.0

<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me" 
       UpgradeCode="$(var.TheUpgradeCodeGUID)">

На машине с установленным 6.0.0.0 я запустил новый установщик.

Удаление старой версии 6.0.0.0 выполняется нормально (все установленные файлы удаляются), но когда установщик продолжает устанавливать новую версию, отсутствуют 2 файла: сторонняя DLL и сторонняя EXE (это не были изменены) не переустанавливаются.

<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
        <File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
        <File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>

Все остальные файлы в <ComponentGroup> (некоторые модифицированные, некоторые немодифицированные, включая другие сторонние DLL) устанавливаются правильно во время основного обновления.

Если я нажму на "repair" после основного обновления, снова появятся 2 отсутствующих файла. Кроме того, если я устанавливаю версию 6.0.1.0 в первый раз (без обновления, но с первой установкой на чистой машине), то эти 2 файла устанавливаются напрямую и обычно. (тестируется на нескольких компьютерах Windows (XP, 7 и 8)

Кто-нибудь может предположить, что не так и как его исправить?

Ответ 1

Предоставленный файл журнала показывает, что более новые версии нескольких файлов уже находятся на машине:

MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists

Я видел эту проблему с этим обновлением в прошлом. Кристофер прав. Обновитель обновил свои файлы, но не сообщил MSI (он не обновляет MSI, что не совсем правильно). Новая MSI думает, что на машине появилось новее, выбирает не устанавливать свои файлы, но во время обновления старый пакет удаляет файлы (он не замечает, что версии новее). Поскольку новый установщик решил не устанавливать файлы, в итоге у вас ничего нет... до ремонта.

Чтобы обойти проблему, вам нужно переместить действие RemoveExistingProducts позже. Если вы используете элемент MajorUpgrade, то Schedule='afterInstallExecute' или Schedule='afterInstallFinalize' должны сделать трюк. Вам нужно быть более осторожным с Правилами компонентов.

Кроме того, стороннему поставщику IMHO не следует обновлять файлы за пределами MSI. Их решение подталкивает ваш продукт к определенному способу обновления.

Ответ 2

Файл журнала поможет. Я предполагаю, что это основано на том, где вы запланировали RemoveExistingProducts. Я видел ситуации, когда Costing вычисляет установленный файл, тот же, что и файл, уже установленный и решает не устанавливать файл. Затем происходит основное обновление, и в итоге у вас нет файла. Ремонт работает, потому что файл отсутствует, а стоимость означает, что он должен быть установлен.

Ответ 3

У меня было другое решение этой проблемы, но предыдущий ответ определенно указывал мне правильное направление. DLL файлам в моем .NET-проекте был присвоен меньший номер версии, чем в моей предыдущей установке. Переход к файлам AssemblyInfo.cs и увеличение третьего октета от 0 до 1 решили эту проблему. Wix теперь распознал библиотеки DLL как более новые.

[assembly: AssemblyVersion("1.0.1.*")]

Ответ 4

В старых версиях установщика Windows проблема документирована здесь:

https://support.microsoft.com/en-us/kb/905238

Список уязвимых продуктов, которые он исправил в MSI 4.0 и более поздних версиях. Использование распространяемого 4.5 перед установкой должно помочь, если это применимо к версии ОС.

Ответ 5

Ошибка все еще существует в установщике 5.0 и по-прежнему является проблемой. Обходное решение для размещения RemoveExistingProduct после InstallFinalize для нас не является решением. Я принудительно изменил настройку свойства в одном файле.

Это решение работает для нас сейчас.

Ответ 6

У меня была такая же проблема. Проблема здесь заключается в том, что при серьезном обновлении msi сначала проверяет, какие компоненты установить (и все библиотеки с более низкой версией, чем уже установленные, помечены как "не устанавливать"), затем удаляет установленное приложение, а затем устанавливает новую версию, но без этих ранее отмеченных компонентов.

Перепланирование REP не помогло, поскольку "запрещение установки (...)" было выполнено на этапе калькуляции, а MajorUpgrade можно запланировать только на этапе установки.

Мое решение состояло в том, чтобы установить для свойства REINSTALLMODE значение "amus" в файле wxs.

<Property Id="REINSTALLMODE" Value="amus" />

"a" означает, что все библиотеки будут переустановлены, несмотря на их версии.