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

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 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>