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

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

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

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

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

Как правильно это сделать?

6 wix
10.12.2008 22:58:59
2 ОТВЕТА

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

<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>
2
11.12.2008 19:09:45

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

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

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

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

4
11.12.2008 19:29:34