Wix major upgrade, замените файлы независимо от более новой версии файла

Question

Мой установщик WiX (Wix 3.10, MSI 4.5) использует MajorUpgrade для обновления. Файлы, которые будут установлены, собираются с heat.exe в предварительной сборке. Текущий (более старый) msi-файл содержит файл nlog.dll (который поставляется с пакетом NuGet v4.1.0), который имеет версию файла 4.1.0.0, версию продукта 4.1.0 и последнее время записи 2015-09-01.

Поскольку Nlog команда столкнулась с некоторыми сильными вопросами именования, они опубликовали обновленный NuGet пакет v4.1.1, содержащее обновленный nlog.dllс его версией файла снизились обратно 4.0.0.0, а его версия продукта была увеличены до 4.1.1, время последней записи есть 2015-09-14.

Теперь я бегу в связи с данным вопросом, как сделал Робби здесь: wix major upgrade not installing all files: Когда я устанавливаю новый пакет MSI и крупное обновление выполняется, настоящее nlog.dll (который новее согласно его версии файла, но старше по к его дате файла и версии продукта) удаляется, но новый nlog.dll не установлен.

Однако, используя Schedule="afterInstallExecute" или Schedule="afterInstallFinalize", как предложено, не будет делать трюк для меня. Вместо того, чтобы удалять новый файл, а не устанавливать более старый, как в случае с Робби, он не перезаписывает настоящий файл и просто оставляет его на месте.

Короче говоря, я хотел бы, чтобы мой установщик просто установил все файлы, которые поставляются вместе с ним, независимо от каких-либо файлов/продуктов для сборки/сборки версий. Существуют действительные обстоятельства, при которых требуется замена нового файла на более старый. Не можете ли вы просто сообщить движку установщика игнорировать версии файлов/даты? Если нет, каковы мои варианты?

Answer 1

Вы можете установить свойство REINSTALLMODE AMUS вместо OMUS. Это затронет все компоненты во всем мире.

Другой трюк заключается в использовании «версии, лежащей». Здесь вы создаете файл с более высокой версией. Использование тепла может сделать это сложным, так как теперь вы должны преобразовать XML перед его компиляцией.

Конечно, реальное решение - поразить команду nlog над головой. Но на основании того, что я видел из них на протяжении многих лет, этого никогда не произойдет. Возможно, вы просто используете редактор ресурсов, чтобы взломать DLL и «исправить» версию #. Это предполагает, что вам не нужно сильное имя. Это чувствует себя грязным и возможный кошмар CM для меня, хотя.

Или просто свалка nlog. :)

Answer 2

Если это серьезное обновление, и вы хотите, чтобы все было удалено до установки нового продукта, тогда вы планируете RemoveExistingProducts после InstallInitialize или InstallValidate. Сначала выполняется удаление.

Я не могу сказать, если вы получаете проблему «запретить установку ...» или нет, но если вы и есть другие клиенты Dll (она используется совместно с другими установленными продуктами) d Посмотрите, поддерживает ли эта Dll личные копии, чтобы у вас была собственная личная копия для вашего продукта. Если он используется совместно с другими продуктами, я бы не использовал версию - я бы открыл Dll с Visual Studio «open as file» и изменил версию! Сделайте свою последнюю общую версию, поэтому каждый пакет, который ее устанавливает, может просто использовать ее.

Если он не используется совместно с другими продуктами, и вы просто работаете с этим приложением MSI, тогда создайте свой собственный элемент обновления и расставьте RemoveExistingProducts перед CostInitialize, что и решает не устанавливать. Это работает, но это до MigrateFeatureStates, поэтому вы потеряете перенос функций в своем основном обновлении.