从控制面板卸载不同于从 .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?
如果有的话是什么?
我之所以这么问是因为以下原因:
I am asking because of the following reason:
区别如下:我的 .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，(创作的用户界面，无向导)
- 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 上进行设置，因为它可能永远不会用于大规模部署方案. 相反，您应该使用可以在 中设置的公共属性来参数化您的安装程序命令行或通过转换，这样您的安装程序就可以轻松控制，而无需交互运行.请参阅此帖子:如何更好地利用 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屋！
