如何在 RemoveExistingProducts 之前使用 After=“InstallValidate”执行自定义操作在 WiX 中
我有这样的事情：
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
由于其中一个卸载失败，我需要在删除现有产品之前执行自定义操作来解决问题。 这当然行不通，
<CustomAction Id="FixStuff" .. />
<InstallExecuteSequence>
<Custom Action="FixStuff" Before="RemoveExistingProducts" />
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
因为自定义操作不能在 InstallInitialize 之前。我真的很想删除 InstallValidate 和 InstallInitialize 之间的现有产品，但我想在删除现有产品之前执行 FixStuff。
有可能这样做吗？
I have something like this:
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
Since one of the uninstallation fails i need to execute a Custom Action to solve the problem BEFORE RemoveExistingProducts. Something in the lines of:
<CustomAction Id="FixStuff" .. />
<InstallExecuteSequence>
<Custom Action="FixStuff" Before="RemoveExistingProducts" />
<RemoveExistingProducts After="InstallValidate"/>
</InstallExecuteSequence>
This of course doesn't work since Custom Action cannot be before InstallInitialize. I'd really like to remove existing products between InstallValidate and InstallInitialize, but i'd like to execute FixStuff before removing existing products.
Is it even possible to do that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
遗憾的是，您无法在使用当前配置的RemoveExistingProducts 之前运行提升的自定义操作。
一些可能的方法是：
将RemoveExistingProducts 移至InstallFinalize 之前。这解决了自定义操作问题，但可能会出现其他问题，因为这种方法有很多限制（组件需要在版本之间维护其名称和 GUID，您的自定义操作应该知道升级是在安装结束时执行的等）。< /p>
创建一个 EXE 引导程序，在启动新 MSI 之前修复旧安装程序。此引导程序可以通过清单要求管理员权限：
http://msdn.microsoft.com /en-us/library/bb756929.aspx
使用以下方法修复损坏的 MSI：
msiexec /fv
当您的新软件包运行 RemoveExistingProducts 时，应修复旧的缓存 MSI，并且应正确卸载。
Unfortunately you cannot run an elevated custom action before RemoveExistingProducts with your current configuration.
Some possible approaches would be:
Move RemoveExistingProducts right before InstallFinalize. This solves the custom action problem, but other problems may occur since this approach has many restrictions (the components need to maintain their names and GUIDs between versions, your custom actions should be aware that the upgrade is performed at installation end etc.).
Create an EXE bootstrapper which fixes the old installer before launching the new MSI. This bootrapper can require Administrator privileges through a manifest:
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Repair the broken MSI by using this method:
msiexec /fv <path_to_msi>
When your new package runs RemoveExistingProducts, the old cached MSI should be fixed and it should uninstall correctly.