Обновление wix major не устанавливает все файлы
У меня есть очень простой проект WiX (версия 3.7), который устанавливает некоторые файлы (программа.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>
Все остальные файлы в
Если я щелкну "восстановить" после серьезного обновления, 2 отсутствующих файла снова появятся. Кроме того, если я устанавливаю версию 6.0.1.0 в первый раз (без обновления, но сначала на чистую машину), то эти 2 файла устанавливаются напрямую и нормально. (протестировано на нескольких машинах Windows (XP, 7 и 8)
У кого-нибудь есть предложения, что не так и как это исправить?
5 ответов
Предоставленный файл журнала показывает, что более новые версии нескольких файлов уже есть на компьютере:
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. Их решение заставляет ваш продукт переходить на определенный способ.
У меня была такая же проблема. Проблема здесь в том, что при крупном обновлении msi сначала проверяет, какие компоненты нужно установить (и все библиотеки DLL с более ранней версией, чем уже установленные, помечаются как "не устанавливать"), затем удаляет установленное приложение, а затем устанавливает новую версию, но без ранее отмеченных компонентов.
Изменение расписания REP не помогло, поскольку "запрет на установку (...)" был выполнен на этапе Costing, а MajorUpgrade можно запланировать только на этапе установки.
Мое решение заключалось в том, чтобы установить для свойства REINSTALLMODE значение "amus" в файле wxs.
<Property Id="REINSTALLMODE" Value="amus" />
"A" означает, что все библиотеки DLL будут переустановлены независимо от их версий.
Файл журнала поможет. Я предполагаю, что это основано на том, где вы запланировали RemoveExistingProducts. Я видел ситуации, когда Costing обнаруживает, что устанавливаемый файл совпадает с уже установленным файлом и решает не устанавливать файл. Затем происходит серьезное обновление, и у вас не получается файл. Ремонт работает, потому что файла нет, и стоимость понимает, что его нужно установить.
У меня было другое решение этой проблемы, но предыдущий ответ определенно указывал мне правильное направление. DLL-файлам в моем проекте.NET был присвоен меньший номер версии, чем в моей предыдущей установке. Переход к файлам AssemblyInfo.cs и увеличение третьего октета от 0 до 1 решили эту проблему. Wix теперь распознал библиотеки DLL как более новые.
[assembly: AssemblyVersion("1.0.1.*")]
Ошибка по-прежнему существует в установщике 5.0 и по-прежнему является проблемой. Обходной путь для размещения RemoveExistingProduct после InstallFinalize это не решение для нас. Я принудительно обновил настройку свойства для одного файла.
Это решение работает для нас сейчас.
В старых версиях установщика Windows проблема описана здесь:
https://support.microsoft.com/en-us/kb/905238
Список затронутых продуктов подразумевает, что это исправлено в MSI engine 4.0 и новее. Использование распространяемой версии 4.5 перед установкой должно помочь, если это применимо к версии ОС.