从控制面板卸载不同于从 .msi 中删除 [英] Uninstall from Control Panel is different from Remove from .msi
问题描述
使用基于 WiX 的 .msi 从控制面板和从 .msi 本身卸载应用程序有区别吗?
Is there a difference between uninstalling an application with WiX based .msi from Control Panel and from the .msi itself?
如果有是什么?
我问是因为以下原因:
区别如下:我的 .msi 将一些文件存储在 %PROGRAMDATA% 中.如果我从控制面板卸载，那里的文件会被卸载(似乎 .msi 会跟踪这些文件(它们被定义为组件))，但是当我打开 .msi 并尝试卸载时(我有一个维护对话框)那些文件不会被删除.
The difference is the following: my .msi stores some files in %PROGRAMDATA%. If i uninstall from Control Panel the files there get uninstalled (it seems that the .msi keeps track of those (they are defined as components)), but when I open my .msi and try to uninstall (I have a maintenance dialog) those files don't get deleted.
另一个区别是:我还有一个自定义操作来停止我的应用程序，如果它正在运行，它在 InstallUISequence 中调用 After="AppSearch"，在 InstallExecuteSequence 中调用 Before="CostFinalize"，但是从 .msi 中删除它时没有被调用.只有一个对话框显示有文件要删除但正在使用，但是有些进程，当我告诉它停止它们时它没有这样做.
Another difference is: I also have a Custom Action to stop my Application if it is running which is being called After="AppSearch" in the InstallUISequence and Before="CostFinalize" in the InstallExecuteSequence but when removing from the .msi it isn't being called. Only a dialog shows that says that there are files to be deleted but are being usedbut some processes and when I tell it to stop them it doesn't do so.
推荐答案
下面的讨论"有点失控了.但我将把它留在这里，作为研究静默模式和交互模式安装之间差异的人们的解释.
The following "discussion" got a little out of hand. But I will leave it here as an explanation for people who research differences experienced between silent mode and interactive mode installs.
是的，简短的回答是您确实可以看到不同的安装或卸载行为，具体取决于您调用(卸载)安装的方式.
Yes, the short answer is that you can indeed see different installation or uninstallation behavior depending on how you invoke the (un)install.
这主要与 MSI 如何以不同的用户界面级别运行有关，这会导致整个用户界面序列(InstallUISequence>) 在 MSI 中运行或完全跳过(静默安装).跳过后，仅在 InstallUISequence 中定义的所有自定义操作将根本不会运行.如果 MSI 设计良好，这不是问题，因为用户界面自定义操作在即时模式下运行，并且不应该对系统进行更改 - 他们应该只查询用户数据和设置、系统状态或帮助用户输入正确的安装数据.如果 MSI 设计不当并且在用户界面中对系统进行了更改，则在静默模式下运行时安装将不完整.这是一个严重的 MSI 设计错误，当您意识到所有大公司都在静默部署软件时，它变得更加严重. 我在进行企业应用程序重新打包时多次看到此类错误.无论软件有多好，这都不是对软件的信任投票.怪异和不可预知的问题必然会浮出水面.
This has mostly to do with how an MSI can run with different user interface levels, and this causes the entire user interface sequence (InstallUISequence) in the MSI to either be run or skipped entirely (silent installation). Once skipped, all custom actions defined only in the InstallUISequence will not run at all. If the MSI is well-designed, this is not a problem since user interface custom actions run in immediate mode and should never make changes to the system - they should just inquire for user data and settings, system state or help the user enter proper data for the installation. If the MSI is not well designed and changes are made to the system in the user interface, the installation will be incomplete when running in silent mode. This is a serious MSI design error which becomes all the more serious when you realized that all major corporations deploy software silently. I have seen such errors many times when doing corporate application repackaging. It is not a vote of confidence for the software, no matter how good it is. Weird and unpredictable problems are bound to surface.
因此，InstallExecuteSequence(这是在静默安装安装程序时唯一运行的一个)应该具有所有必需的自定义操作，以便在其中插入系统更改以正确设计 MSI.如前所述，仅存在于用户界面序列中的自定义操作应处理从用户获取值和设置，而这些值应由命令行设置和定义，或在静默安装的转换中定义.
Accordingly, the InstallExecuteSequence (which is the only one that runs when the setup is installed silently) should have all required custom actions that make system changes inserted there for an MSI to be correctly designed. As already stated, custom actions existing only in the user interface sequence should deal with getting values and settings from the user, whereas these values should be set and defined by command line or defined in transforms for a silent install.
自定义操作条件的某些奇怪和错误组合也可能在特殊情况下导致交互式安装和静默安装之间的差异.最后，在 InstallExecuteSequence 中的 InstallFinalize 之后放置自定义操作可能会导致操作在静默运行时失败.当然还有其他潜在问题.
Certain odd and erroneous combinations of custom action conditions can also cause differences between interactive and silent installs in special circumstances. And finally putting custom actions after InstallFinalize in the InstallExecuteSequence can cause actions to fail when run silently. There are certainly other potential problems as well.
总而言之，如果您确实发现基于用户界面级别的安装行为有所不同，则您的 MSI 包含一个严重的设计缺陷.您应始终确保您的 MSI 可以以静默方式运行，并获得与交互方式相同的结果.如前所述，大公司从不以交互方式运行安装，因为他们通过软件管理系统(如 SCCM)推出软件.
In summary, if you do see a difference in installation behavior based on the user interface level, your MSI contains a serious design-flaw. You should always ensure that your MSI can be run silently with the equivalent result as interactively. And as already stated large corporations never run installations interactively since they push out software via software management systems such as SCCM.
有 4 个 MSI UI 级别，从完全静音到完全交互:
- INSTALLUILEVEL_NONE = 2，(完全静音)
- INSTALLUILEVEL_BASIC = 3，(进度条和简单的错误处理)
- INSTALLUILEVEL_REDUCED = 4，(编写的 UI，无向导)
- INSTALLUILEVEL_FULL = 5(完整用户界面)
有一个 MSI 属性 UILevel 保持 GUI 级别值 2、3、4 或 5.如果您的自定义操作必须考虑用户界面类型，请选中此属性.这对于不应该显示任何对话框的完全静默安装来说显然是最重要的.
There is an MSI property UILevel holding the GUI level value 2, 3, 4 or 5. Check this property if your custom action must take the user interface type into account. This is obviously most important for totally silent installs that should never show any dialogs.
当您右键单击 MSI 并选择卸载时，您通常正在运行 UILevel 3(带进度条的基本 UI).这意味着 InstallUISequence 被跳过.
When you right click an MSI and select uninstall you are generally running UILevel 3 (Basic UI with progress bar). This means the InstallUISequence is skipped.
总而言之，错误可能仅在其中一种模式(静默/非静默)中出现，因为 MSI 的用户界面序列连同其针对某些用户界面级别的所有自定义操作都被跳过了.换句话说，如果 MSI 设计不当，产品可能会在交互式安装时工作，而在静默安装时失败(反之亦然).
In summary, it is possible for bugs to occur in only one of the modes (silent / non-silent) because the MSI's user interface sequence is skipped along with all its custom actions for certain user interface levels. In other words, a product could work when installed interactively and fail when installing silently (or vice versa), if the MSI is badly designed.
也可能基于此 UILevel 功能，因此结果因安装模式而异.我已经看到人们在主安装序列中放置的自定义操作中的代码生成对话框(不允许交互)，然后使用 UILevel 检查以在静默安装模式下抑制对话框(或者他们也忘记了这一点，触发隐藏的模态对话框，在静默模式下运行时停止安装死机).这些奇怪的设计结构会根据安装的触发和运行方式导致意外的安装行为.
It is also possible to condition custom actions in the main MSI installation sequence erronously based on this UILevel feature so that results differ based on installation mode. I have seen people spawn dialogs from code in custom actions placed in the main installation sequence (where no interactivity is allowed) and then use UILevel checks to suppress the dialog in silent installation mode (or they forget that as well, triggering a hidden modal dialog that stops the install dead when running in silent mode). These weird design constructs cause unexpected installation behavior based on how the install is triggered and run.
虽然这不是你所问问题的答案，最终结论是，如果你的软件是为大公司设计的，你不应该浪费你的设计精力在用于您的设置的高级 GUI 上，因为它可能永远不会用于大规模部署场景. 相反，您应该使用可以在 设置的 公共属性 参数化您的安装程序命令行或通过transform，这样您的安装程序就可以轻松控制，而无需以交互方式运行它.请参阅此帖子:如何更好地利用 MSI 文件.
Though this is sort of not an answer to what you asked, a final conclusion from all of this is that if your software is intended for large corporations you should not waste your design efforts on an advanced GUI for your setup as it is likely never to be used for large-scale deployment scenarios. Rather you should parameterize your installer with public properties that can be set at the command line or via a transform so that your installer can be controlled easily without running it interactively. See this post: How to make better use of MSI files.
由于我已经远远超出了您的问题，我还应该注意一些用于服务器安装的高级安装程序可能(适度)受益于良好的 GUI，以帮助人们快速获得您的服务器软件安装和测试.这些安装程序倾向于使用非常高级的功能，例如 IIS、MS SQL、AD 等……对于知识渊博的系统管理员来说，可能需要一些交互性.但俗话说大多数东西都可以默认"，好的默认设置通常更容易让人们安装和测试，无论是否有知识.如今，许多大公司运行大型虚拟服务器农场(每个用例一个虚拟服务器)，因此即使是服务器安装也倾向于自动化以进行大规模部署，然后具有要设置的公共属性的良好参数化安装程序值得赞赏.较小的公司也可能有虚拟服务器(使测试变得容易)，但他们可能会以交互方式安装您的设置，接受任何默认设置 - 至少这是我的印象.
Since I have gone so far beyond your question, I should also note that some advanced installers intended for server installations may (with moderation) benefit from a good GUI to help people quickly get your server software installed and tested. These installers tend to meddle with very advanced features such as IIS, MS SQL, AD, etc... and some interactivity could be desired for knowledgeable system administrators. But as the saying goes "most things can default" and good default settings are generally easier for people to get installed and tested whether knowledgeable or not. Many large companies run large farms of server virtuals these days (one virtual server per use case), so even server installs tend to get automated for large-scale rollout and then a good parameterized installer with public properties to set is appreciated. Smaller companies may also have server virtuals (making testing easy), but they are likely to install your setup interactively accepting whatever defaults are there - at least that is my impression.
链接:
这篇关于从控制面板卸载不同于从 .msi 中删除的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
