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

Я работаю над функцией обновления для моего установщика на базе WiX.

Как часть установки, мы устанавливаем файл web.config, а затем используем настраиваемое действие для обновления строк подключения внутри файла.

Но это вызывает проблему при запуске нашего обновления. Мы хотели бы, чтобы RemoveExistingProducts планировалось после InstallFinalize, поскольку это наиболее эффективно с точки зрения не удаления и переустановки файлов, которые не изменились. Но это оставляет исходный файл web.config на месте в то время, когда установщик Windows пытается определить, следует ли его обновлять или нет. Поскольку последняя измененная дата более поздняя, чем дата создания, установщик Windows решает не обновлять его (см. правила управления версиями, которые использует установщик Windows). Но нам нужно, чтобы он обновлялся.

Одним из очевидных решений является изменение планирования RemoveExistingProducts после InstallValidate - но это неэффективно, а также, я не думаю, что это даст нам возможность перенести настройки из существующих файлов, если нам нужно это сделать.

Любые другие идеи?

Ответ 1

Существует много способов - ни один из них не идеален.

1: вы можете использовать сопутствующий файл, чтобы принудительно обновить файл. При условии, что указанный файл сопутствующих файлов всегда обновляется, это может быть путь. По сути, это означает, что вы связываете не-версированный файл с логикой обновления версии своего сопутствующего файла (файлы обновляются вместе). Я никогда не использовал это в WIX, но мне кажется, что это просто, как добавление атрибута CompanionFile к элементу File и указывать на идентификатор файла, который вы хотите использовать "версия". Внутри файла MSI он будет выглядеть примерно так:

2: вы можете использовать настраиваемое действие для удаления файла до загрузки файла (или, еще лучше, переименовать его в формат резервной копии). Проблема в том, что если сбой установки, файл будет отсутствовать. Если вы переименуете файл, а не удаляете, вы можете вернуть его обратно, если установка завершится неудачно с помощью специального действия отката. Иногда я использую таблицу RemoveFile для удаления файлов при установке, но в зависимости от последовательности, указанной в InstallExecuteSequence, это может не работать (удаление должно происходить до того, как msi выполнит обработку файла).

3: Тогда подход кувалды: установите ~~REINSTALLMODE = amus~~, чтобы принудительно перезаписать все файлы независимо от версии. Я не должен упоминать об этом, так как это ужасно опасно (вы можете закончить переписывание системных файлов, или в новых версиях Windows запускать неприятную ошибку времени выполнения, поскольку файлы защищены). Используйте его только для тестирования dev, и не думайте, что это быстрое решение. Это вызывает больше проблем, чем решает.

В качестве варианта приемлемым подходом может быть установка REINSTALLMODE в emus (заменить старые и те же файлы версий). Это может помочь, если вы не хотите увеличивать номера версий, но продолжайте перестраивать свои двоичные файлы - как это происходит во многих .NET. Я предполагаю, что это приведет к появлению целого ряда новых проблем - наиболее значимых двоичных, но идентичных файлов версий в дикой природе, если вы используете его для публичных выпусков - запах развертывания если когда-либо был. Однако, как подход QA/DEV, он может работать. Но серьезно, зачем беспокоиться? Просто автоматически увеличивайте версию сборки двоичных файлов, и проблема решается надежно.

Ответ 2

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