从控制面板卸载不同于从.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.
是，简而言之，就是您确实可以看到不同的安装或卸载行为，具体取决于您调用(un)install 的方式.
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.
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 功能，因此结果因安装模式而异.我已经看到人们从代码中以主安装顺序(不允许交互)中的自定义操作生成对话框，然后使用
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.
链接 :
Links:
