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

Question

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

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

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

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

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

Answer 1

Я думаю, что нет никакого «чистого» способа сделать это, потому что проект 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> 

Answer 2

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

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

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

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