wix - 从控制面板卸载与从.msi删除不同

Question

从控制面板和.msi本身卸载基于WiX的.msi的应用程序是否有区别？

如果有什么？

我问是因为以下原因：

区别如下：我的.msi文件将某些文件存储在％PROGRAMDATA％中。如果我从“控制面板”中卸载，那里的文件将被卸载（.msi会跟踪那些文件（它们定义为组件）），但是当我打开.msi并尝试卸载（我有一个维护对话框）时文件不会被删除。

另一个区别是：如果应用程序正在运行，我还有一个自定义操作来停止我的应用程序，该应用程序在InstallUISequence中被命名为After =“ AppSearch”，在InstallExecuteSequence中被命名为Before =“ CostFinalize”，但是从.msi中删除时，它不是被呼叫。只有一个对话框显示，有一些文件要删除但正在使用，但是有些进程正在运行，而当我告诉它停止文件时，它并没有这样做。

Answer 1

以下“讨论”有些失控。但是，我将在此留给那些研究静默模式和交互模式安装之间的差异的人们做一个解释。

是的，简短的答案是，根据调用（卸载）安装的方式，您确实可以看到不同的安装或卸载行为。

这主要与MSI如何以不同的用户界面级别运行有关，这导致MSI中的整个用户界面序列（InstallUISequence）可以运行或完全跳过（静默安装）。一旦跳过，仅在InstallUISequence中定义的所有自定义操作将根本不会运行。如果MSI设计合理，则这不是问题，因为用户界面自定义操作以即时模式运行，并且永远不要对系统进行更改-它们应该只是查询用户数据和设置，系统状态或帮助用户输入正确的数据。用于安装。如果MSI的设计不正确，并且在用户界面中对系统进行了更改，则在静默模式下运行时安装将不完整。这是一个严重的MSI设计错误，当您意识到所有主要公司都在静默部署软件时，该错误会变得更加严重。在进行公司应用程序重新打包时，我已经多次看到这样的错误。不管软件多么出色，这都不是对该软件的信任。怪异而无法预测的问题势必浮出水面。

因此，InstallExecuteSequence（这是在无提示安装安装程序时运行的唯一程序）应该具有所有必需的自定义操作，这些操作将对系统进行更改，以便正确设计MSI。如前所述，仅在用户界面序列中存在的自定义操作应处理从用户获取值和设置的问题，而这些值应由命令行设置和定义，或在无提示安装的转换中定义。

自定义操作条件的某些奇数和错误组合也会在特殊情况下导致交互式安装和静默安装之间的差异。最后，将自定义操作放在InstallExecuteSequence中的InstallFinalize之后可能会导致操作在静默运行时失败。当然也存在其他潜在问题。

总而言之，如果您确实发现基于用户界面级别的安装行为有所不同，则您的MSI包含严重的设计缺陷。您应始终确保MSI可以以与交互操作等效的结果静默运行。如前所述，大型公司从未通过交互式方式运行安装，因为它们通过诸如SCCM之类的软件管理系统推出软件。


有4种MSI UI级别，从完全静音到完全交互式：


INSTALLUILEVEL_NONE = 2，（完全静音）
INSTALLUILEVEL_BASIC = 3，（进度条和简单的错误处理）
INSTALLUILEVEL_REDUCED = 4，（授权用户界面，无向导）
INSTALLUILEVEL_FULL = 5（完整用户界面）

重要的一点是，对于UILevel 2和3，将跳过InstallUISequence。
有一个MSI属性UILevel保持GUI级别值为2、3、4或5。如果您的自定义操作必须考虑用户界面类型，请检查此属性。对于绝对不显示任何对话框的完全静默安装，这显然是最重要的。
右键单击MSI并选择卸载时，通常会运行UILevel 3（带有进度栏的基本UI）。这意味着将跳过InstallUISequence。
从添加/删除程序卸载时，普通的UILevel也是3-基本用户界面。这意味着InstallUISequence也将被跳过。
如果双击MSI并运行卸载，则GUI级别为5-完整GUI。如果在添加/删除程序中选择“更改”，也会发生相同的情况。


总之，由于MSI的用户界面序列以及针对某些用户界面级别的所有自定义操作都被跳过，因此错误仅可能在一种模式下发生（无声/无声）。换句话说，如果MSI设计不良，则在交互式安装时产品可以工作，而在静默安装时产品会失败（反之亦然）。

也可以根据此UILevel功能在MSI主安装序列中错误地调整自定义操作，以使结果因安装模式而异。我见过人们从代码中以主安装顺序（不允许交互）中的自定义操作生成对话框，然后使用UILevel检查以静默安装模式禁止对话框（或者他们也忘记了这一点，触发了隐藏操作）模式对话框，以静默方式运行时停止安装。这些奇怪的设计构造基于触发和运行安装的方式导致意外的安装行为。

尽管这不能完全解决您的要求，但所有这些的最终结论是，如果您的软件是为大型公司设计的，则不应在高级GUI上浪费设计工作，因为它可能永远不会用于大规模部署方案。相反，您应该使用可在命令行或通过转换设置的公共属性来对安装程序进行参数化，以便可以轻松控制安装程序而无需交互运行它。看到这篇文章：How to make better use of MSI files。

由于我已经远远超出了您的问题，因此我还应该指出，一些用于服务器安装的高级安装程序可以（适度）从良好的GUI中受益，以帮助人们快速安装和测试服务器软件。这些安装程序倾向于混入非常高级的功能，例如IIS，MS SQL，AD等...，并且有经验的系统管理员可能需要一些交互功能。但是俗话说“大多数事情都是默认的”，良好的默认设置通常使人们更容易安装和测试知识是否丰富。如今，许多大公司都在运行大型服务器虚拟服务器场（每个用例一个虚拟服务器），因此即使服务器安装也可以自动进行大规模部署，然后对具有公共属性进行设置的良好参数化安装程序表示赞赏。较小的公司可能也有服务器虚拟机（使测试变得容易），但是它们很可能以交互方式安装您的安装程序，接受那里的任何默认设置-至少这是我的印象。



链接：


Is it possible to passively install an .EXE but still show the GUI using Powershell?