我想将转换(.mst)文件写入现有的安装程序(.msi)文件,以便正确管理作为安装一部分的服务。也就是说,服务的可执行文件是msi的一部分,但是msi并不“意识到”这是服务。预定义的InstallExecuteSequence的运行方式如下:
Action Condition Sequence
...
InstallValidate <null> 1400
RemoveExistingProducts AI_UPGRADE<>"NO" 1450
InstallInitialize <null> 1500
...
StopServices VersionNT 1900
DeleteServices VersionNT 2000
...
RemoveFiles <null> 3500
...
InstallFiles <null> 4000
...
InstallServices VersionNT 5800
StartServices VersionNT 5850
...
InstallFinalize <null> 6600
我在MST中要做的第一件事是将适当的条目添加到(最初为空或什至不包括在内)表ServiceControl
和ServiceInstall
中。到目前为止,一切都很好。
但是,我现在对InstallExecuteSequence以及是否应该推销与服务相关的四个操作的位置感到怀疑:
Documentation上面所说的关于RemoveExistingProducts
的说法是这样的:
在这种情况下,安装程序会在安装新应用程序之前完全删除旧应用程序。此操作的效率很低,因为必须重新复制所有重复使用的文件。
这让我有些困惑。是不是在RemoveFiles
和InstallFiles
(也许还有一些相关的)操作中完成了文件的删除和复制(是否重复使用)?
某种程度上,以上引用似乎暗示(在升级的情况下)我的服务exe文件的旧版本将在服务停止之前(甚至在InstalInitialize
开始安装事务之前被新版本替换)! ?)
这是否意味着我应该考虑在MST中重新定位RemoveExistingProducts
操作?还是在RemoveExistingProducts
之前重新定位“停止/删除服务”操作,并相应地在安装事务结束后(即InstallFinalize
之后)重新定位“安装/启动”服务操作?这似乎也不正确-当然,这些动作应由事务保护(特别是在首次安装或完全卸载期间必须回滚事务的情况下)。
我的直觉是我不应该担心,一切都按原样进行,我只是误解了一些东西。因此,如果有人能启发我,我将不胜感激。
答案 0 :(得分:1)
这会有些仓促,稍后会回头-未完成质量检查:
卸载 :
RemoveExistingProducts
实际上是现有InstallExecuteSequence
安装产品-在主要升级过程中将其卸载 正在跑步。所以整个“内”RemoveExistingProducts
会卸载旧版本的产品。内 其他版本的InstallExecuteSequence
您怀疑是否由RemoveFiles
完成文件操作,然后 控件将返回到新MSI中的原始位置。像一个 换句话说,函数调用-它返回到卸载位置 调用。
服务 :我会保留您在问题中显示的顺序。
StartServices
和 InstallServices
应该在 RemoveFiles
和 {{1 }} InstallFiles
和 StopServices
应该在 DeleteServices
和 {{1 }} 。 RemoveExistingProduct Placement :如果更改 InstallFiles
的位置,则将在不同的排序选项之间进行切换,以进行主要升级卸载和重新安装行为:
主要升级 :以上两个总体排序选项和the WiX documentation lists them here有几种风格。这是 InstallServices
属性。有很多选项-每个选项都有重要的怪癖和因素: RemoveExistingProducts
, Schedule
, afterInstallValidate
, afterInstallInitialize
, afterInstallExecute
。 请仔细阅读链接的文档。