2008-12-10 76 views
5

我有一个包含配置参数和其他数据随用户使用应用程序而改变的多个文件的应用程序。这些文件可以随着我的软件的更新版本而改变,但是用户也可以修改它们(或者它们可能被应用程序本身改变)。基本上,我正在寻找一种解决方案来防止用户对这些文件所做的更改被覆盖,同时也是在用户升级我的软件时安装可能更新的文件的一种方法。使用WiX管理配置文件

对于* NIX上的RPM,您可以使用%config函数将文件定义为配置文件,然后RPM会重命名现有文件(如果存在)并在升级时安装新文件(可能不理想,但我可以为这样的WiX生活)。

我想将我的配置文件安装到子目录或甚至不同的名称(例如default.cfg),然后使用WiX中的<CopyFile>元素将文件复制到正确的位置。这样,默认文件将在安装时被删除并在升级时被覆盖,但实际的用户文件将保持不变。不幸的是,<CopyFile>,Windows安装程序仍然想要管理(并删除)目标文件。

我也考虑过在WixUtilExtension中使用QtExec动作,基本上是做“复制default.cfg reallocation.cfg”,但这不起作用,而且有点破解。

处理这个问题的正确方法是什么?

回答

2

我认为没有“干净”的方式来做到这一点,因为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> 
4

我的建议通常是在一个单独的文件中的用户可编辑的内容和管理通过应用程序,而不是安装。这也意味着单独的文件是“用户内容”,应该不在安装中。

我发现试图以声明方式执行用户数据迁移,看起来很难。试图在安装时进行安装,卸载,修复,修补和回滚所有这些情况只会使情况变得更糟。

例如,RPM行为对“修复”做了什么?复制用户数据并将其替换为一个好文件?这可能是正确的60% - 80%的时间。并卸载,该文件应该被删除?如果用户只是升级到下一个版本,这很棘手。

同样,最好让他们决定如何调整配置。恕我直言。