MSI 主要升级覆盖规则 [英] MSI Major Upgrade overwriting rules
问题描述
我想我在某处读过它,但现在找不到源并且无法确认:当从 MSI 安装(主要升级)较新版本时,如果文件已被修改(由安装程序或用户),默认规则是旧文件不会被新版本的相同文件替换?
I think I read it somewhere, but couldn't find the source now and can't confirm it: when install(Major upgrade) a newer version from MSI, if the file has been modified (either by installer or user), the default rule is that old file wouldn't be replaced by the same file from a new version?
我想我也观察到了我之前编写的安装程序中的行为,但现在经过一些更改,似乎它总是会替换旧的修改过的配置文件!
I think also I observed that behavior in the installer I wrote before, but now after a few changes, seems that it will always replace the old modified config files!
产品定义:
<Product Id="*" Name="$(var.ProductName)" Language="1033" Version="$(var.ProductVersion)" Manufacturer="Advanced Software Solution" UpgradeCode="$(var.UpgradeCode)">
<Package Id="*" InstallerVersion="200" Description="The web service installer" Compressed="yes"
InstallScope="perMachine"/>
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
组件定义:
<Component Id='WebConfigComp' Guid='GUID'>
<File Id='WebConfigFile' Name='Web.config' Source='$(var.TheWebService.WCF.TargetBinPath)Web.Distribution.config'
KeyPath='yes'>
</File>
</Component>
安装执行序列
FindRelatedProducts 25
AppSearch 50
LaunchConditions 100
ValidateProductID 700
myScripts_CA 799
CostInitialize 800
FileCost 900
CostFinalize 1000
MigrateFeatureStates 1200
InstallValidate 1400
RemoveExistingProducts 1401
InstallInitialize 1500
BackupCA Installed 1501
ProcessComponents 1600
UnpublishFeatures 1800
SchedSecureObjectsRollback_x64 VersionNT > 400 1801
RemoveFiles 3500
RemoveFolders 3600
CreateFolders 3700
InstallFiles 4000
InstallServices VersionNT 5800
SchedSecureObjects_x64 NOT REMOVE~="ALL" AND VersionNT > 400 5801
ConfigureIIs NOT SKIPCONFIGUREIIS AND VersionNT > 400 5999
RegisterUser 6000
RegisterProduct 6100
PublishFeatures 6300
PublishProduct 6400
InstallFinalize 6600
LunchWCFReadme NOT Installed 6601
更新:我刚刚创建了一个新项目进行测试,观察到相同的行为(修改后的文件被更新版本的安装程序替换)而不更改默认的 InstallExecSequence.这可能意味着即使文件版本控制应该适用,但它实际上并没有影响预期的结果,因为旧版本的删除发生得太早了,因为 Glytzhkof 和 PhilDW 指出,这是默认的.
Update: I just created a new project for testing, the same behavior observed (the modified file is replaced by the newer version of installer) without change the default InstallExecSequence. Which probably means even though the File Versioning should applies, but it not actually kicked in to affect the result would expected as Remove of old version happened too early be default as Glytzhkof and PhilDW pointed out.
我正在使用当前稳定的 Wix 3.8,我错过了什么吗?
I am using Wix 3.8, the current stable, did I missed something?
更新 2:到目前为止,我可以确认在 InstallFiles
之后移动 RemoveExistingProducts
将保留修改后的未版本控制文件.但问题是似乎 MajorUpgrade
与
Update2:
So far, I can confirm that moving RemoveExistingProducts
after InstallFiles
will keep the modified unversioned files. But the problem is that seems MajorUpgrade
conflict with
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallExecute" />
</InstallExecuteSequence>
我正在添加,错误信息是
I am adding, and the error message is
错误 1 重复符号'WixAction:InstallExecuteSequence/RemoveExistingProducts' 找到.这通常意味着一个 Id 是重复的.检查以确保您的所有给定类型(文件、组件、功能)的标识符是独特的.C:TestDevMySetupTestMySetupTestProduct.wxs 5 1 MySetupTest
Error 1 Duplicate symbol 'WixAction:InstallExecuteSequence/RemoveExistingProducts' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique. C:TestDevMySetupTestMySetupTestProduct.wxs 5 1 MySetupTest
这也不是很有帮助.
最终更新:在挖掘了一段时间的网络之后,找出问题所在:
Final Update: After digging the web thing for a while, find out what the issue is:
默认情况下,MajorUpgrade 将 RemoveExistingProducts 安排在安装验证.您可以使用计划更改计划属性.例如,如果您选择在之后安排InstallInitialize,它将如下所示:
By default, MajorUpgrade schedules RemoveExistingProducts after InstallValidate. You can change the scheduling using the Schedule attribute. For example, If you choose to schedule it after InstallInitialize, it will look like the following:
<MajorUpgrade
Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit.">
来源:Wix 工具集网站
因此,包含 MajorUpgrade
确实会为您更改 RemoveExistingProducts
序列,这是一个有用的功能,但对我来说却是意料之外的.感谢所有的帮助,现在事情开始对我有意义.毕竟是幸福的结局!
So including of MajorUpgrade
will indeed change RemoveExistingProducts
sequence for you, which is a useful feature to have, but was unexpected for me. Thanks for all the help, now things starting make sense to me. An happy ending after all!
推荐答案
当重大升级在安装新版本之前卸载现有安装(在 InstallInitialize 之前删除ExistingProducts)通常会删除最初安装的所有文件 - 这包括文件可能已被修改.然后新版本将与新的文件包一起安装.
When a major upgrade uninstalls an existing installation before the new version gets installed (RemoveExistingProducts before InstallInitialize) it will normally remove all files that were originally installed - this includes files that may have been modified. Then the new version is installed with a fresh bundle of files.
如果您在 InstallFinalize 之后安排 RemoveExistingProducts,则新版本文件的安装会先于过时文件的删除.在这种情况下,文件只有在版本控制且比已安装文件更新时才会被替换,对于 txt、pdf 等无版本文件,文件替换规则基本上规定文件只有在没有被更改的情况下才会被覆盖磁盘.
If you schedule RemoveExistingProducts after InstallFinalize the install of the new version's files precedes the removal of obsolete files. In this scenario files are only replaced if they are versioned and newer than installed files, and for unversioned files like txt, pdf, etc... the file replacement rules basically states that the file will only be overwritten if it has not been changed on disk.
因此,在 InstallFinalize 之后移动 RemoveExistingProducts 可能会解决您的文件替换问题",这实际上是在您当前的升级策略下卸载并重新安装修改后的文件的情况.
It follows that moving RemoveExistingProducts after InstallFinalize may solve your file "replacement problem" which is really a case of the modified files being deleted during uninstalland reinstalled by your current upgrade strategy.
这篇关于MSI 主要升级覆盖规则的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!