避免使MSI进入兼容模式“ Windows的早期版本”

Question

我有一个用于32位应用程序的安装程序包（由MakeMsi构建，最初用于Windows XP，从那时起一直进行简单维护），但该程序包在现代（64位）Windows系统（7、8、10）上注册COM服务器失败。 。 这是我尝试正常安装MSI时看到的内容：

应用程序错误

xyz模块中000F0B01处的异常EOleSysError。 访问OLE注册表时出错。

如果我将MSI置于Windows的早期版本的兼容模式下 ，则COM服务器成功注册。 由于以某种方式“有效” ，因此到目前为止，我没有花太多时间来探究原因。 但是最后，我筋疲力尽，一次又一次地记住我们的客户（有时也包括我自己），所以我想解决这个问题。

注册（和注销）是通过CustomAction进行的，正如我所看到的那样，它使用的是Orca：

"[INSTALLDIR.MYAPP]\placeholder.exe" -regserver
"[INSTALLDIR.MYAPP]\placeholder.exe" -unregserver

对于这些条目中的每一个， Type是1122 ， Source是INSTALLDIR.MYAPP 。

我可以想象COM服务器在安装过程中没有足够的特权启动，但是安装程序不是以管理员权限自动运行吗？ 我的意思是，当我（以标准用户身份）双击安装程序时，它会在实际安装之前显示UAC提示。 为什么COM服务器的注册和注销注销权限较高？ 令人困惑...

如何更改我的MSI，以使Windows安装程序成功处理它？

Answer 1

我假设您知道问题出在作为自定义操作运行的可执行文件中，而不是Windows Installer中的任何文件。 这意味着问题将是可执行文件中的代码，并且可能是较旧的并且与更高版本的OS不兼容。 您需要查看代码以查看其不支持的功能。

许多安装都不会干扰自我注册。 该数据是所有静态数据，只能提取一次并包含在注册表项和其他COM类表的MSI文件中。 这意味着在安装过程中根本不需要运行代码。

Answer 2

在学习了如何以正确的方式注册COM服务器之后，我仍然很想了解为什么我的MSI包以前可以工作。 换句话说：Windows XP之后的关键变化是什么？
...同时我还检查了以管理员身份运行MSI时是否可以正常运行...

正如我在阅读WiX工具集文档时发现的那样，有一个Impersonate for CustomAction属性，用于控制是否以提升的特权执行CA：

此属性指定在执行此自定义操作时，是否作为本地系统执行的Windows Installer应该模拟安装用户的用户上下文。 通常，该值应为“是”，除非自定义操作需要提升的特权才能将更改应用于计算机。

它引用CustomAction表的Type字段中的msidbCustomActionTypeNoImpersonate标志 。 我在MSI中观察到的值1122被反编译为：

• 1024（标志）： msidbCustomActionTypeInScript ，或者推迟执行，在安装脚本中运行
• 64（标志）： msidbCustomActionTypeContinue ，或者， 忽略退出代码并继续
• 34： 自定义操作类型34 ，或者通过命令行启动可执行文件

我用来快速解决此问题的快速方法是，在CA类型中启用msidbCustomActionTypeNoImpersonate标志（ 2048 ）（在WiX中为Impersonate="no" ）。

转换为我的MakeMsi脚本后，我不得不使用 ExeCa命令 的Type中的System属性，以像以前一样使自注册工作：

Type="Deferred Sync AnyRc System"

我完全意识到这只是一种解决方法，因为运行COM服务器进行（取消）注册很危险。 因此，应该首选PhilDWs答案的第二部分中提到的解决方案： 通过MSI中的注册表项管理与COM相关的静态信息。 但是有时您需要快速的解决方案，有时则没有其他选择，请参阅Euro Micellis评论 。