Управляйте файлами конфигурации с помощью WiX

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

С RPM на *NIX вы можете использовать функцию %config, чтобы определить файл как файл конфигурации, а затем RPM переименует существующий файл (если он существует) и установит новый при обновлении (возможно, не идеально, но я мог бы жить с чем-то вроде этого для WiX).

Я хотел бы установить свои файлы конфигурации в подкаталог или даже под другим именем (например, default.cfg), а затем использовать элемент <CopyFile> в WiX, чтобы скопировать файлы в правильные места. Таким образом, файлы по умолчанию будут удалены при установке и перезаписаны при обновлении, но фактические пользовательские файлы останутся прежними. К сожалению, с <CopyFile> установщик Windows по-прежнему хочет управлять (и удалять) целевым файлом.

Я также рассматривал возможность использования действия QtExec в WixUtilExtension, чтобы в основном сделать «копировать default.cfg reallocation.cfg», но это не совсем сработает, и это немного хак.

Каков правильный способ справиться с этим?


wix
person Jason    schedule 10.12.2008    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Я обычно рекомендую размещать редактируемый пользователем контент в отдельном файле и управлять им через приложение, а не через установку. Это также означает, что отдельный файл является «пользовательским содержимым» и его следует исключить из установки.

Я обнаружил, что попытка выполнить декларативную миграцию пользовательских данных обманчиво сложна. Попытка сделать это во время установки, когда вам нужно продумать установку, удаление, восстановление, исправление и откат для всех этих случаев, только усугубляет ситуацию.

Например, что делает поведение RPM при «ремонте». Скопировать пользовательские данные и заменить их хорошим файлом? Вероятно, это правильно в 60-80% случаев. И удалить, должен ли файл быть удален? Это сложно, если пользователь собирается просто перейти на следующую версию.

Опять же, лучше позволить им решать, что делать со своими настройками конфигурации. ПО МОЕМУ МНЕНИЮ.

person Rob Mensching    schedule 11.12.2008

arrow_upward
2
arrow_downward

Я думаю, что нет «чистого» способа сделать это, потому что проект msi должен иметь возможность полностью удалить себя по замыслу. Я думаю, что лучший способ решить эту проблему — использовать настраиваемое действие, которое выполняет пакетный файл и помещает логику обновления файла конфигурации в этот пакетный файл. Пользовательское действие выглядит следующим образом (только соответствующие части):

<Directory Id="MYDIR" Name="MyDir">
    <Component Id="update.cmd" Guid="YOUR-GUID">
        <File Id="update.cmd" Name="update.cmd" KeyPath="yes" 
                Source="source\update.cmd" />
    </Component>
</Directory>

<CustomAction Id='RunUpdate' Directory='MYDIR' 
        ExeCommand='[SystemFolder]cmd.exe /c update.cmd' Return='ignore'/>

<InstallExecuteSequence>
    <Custom Action='RunUpdate' After='InstallFinalize'>NOT Installed</Custom>
</InstallExecuteSequence>
person wimh    schedule 11.12.2008