避免将MSI置于兼容模式＆＃34;以前版本的Windows＆＃34;

Question

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

  

应用程序错误

     

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

如果我将MSI置于兼容模式以前版本的Windows ，则COM服务器会成功注册。由于＆＃34;它的工作＆＃34; 不知何故，到目前为止，我没有花太多时间探索原因。但最后，我已经筋疲力尽地一次又一次地记住我们的客户（有时也是我），所以我希望解决这个问题。

注册（和取消注册）是通过 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

在学习了如何register COM servers the right way后，我仍然有兴趣了解为什么我的MSI包之前有效。换句话说：Windows XP之后的关键变化是什么？
...我同时还检查了当我以管理员身份运行时MSI正常工作......

当我想到阅读WiX工具集文档时，Impersonate有一个属性CustomAction来控制CA是否以提升的权限执行：

  

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.

它指的是msidbCustomActionTypeNoImpersonateflag的Type字段中的CustomAction Table。我在MSI中观察到的值1122被反编译为：

• 1024（flag）：msidbCustomActionTypeInScript，或延迟执行，在安装脚本中运行
• 64（flag）：msidbCustomActionTypeContinue，或忽略退出代码并继续
• 34：Custom Action Type 34，或通过命令行启动可执行文件

我过去常常＆＃34;修复＆＃34;快速方法的问题是，在CA类型中启用msidbCustomActionTypeNoImpersonate标志（2048）（在WiX中，这将是Impersonate="no"）。

转换为我的 MakeMsi 脚本，我必须使用 {{3}的System 中的Type属性以使自己的注册工作像以前一样：

Type="Deferred Sync AnyRc System"

我完全清楚这只是一种解决方法，因为为（un-）寄存器运行COM服务器很危险。因此，应优先考虑ExeCa command第二部分中提到的解决方案：通过MSI中的注册表项管理与COM相关的静态信息。但有时您需要快速解决方案，有时还需要没有其他选择，请参阅PhilDWs answer。