向项目添加新的自定义操作会阻止运行现有的自定义操作 [英] Adding a new Custom Action to a project prevents an existing Custom Action from being run

问题描述

我有一个自定义操作项目，其中包含我公司创建的安装程序使用的各种 CA，其中一些用于通过 Microsoft.Web.Administration API 操作 IIs7.

我在包含 IIs 相关 CA 的类中添加了一个名为 SetApplicationAutoStart 的新自定义操作.此自定义操作用于设置强制 II 预加载和启动 WCF 服务的 autoStart 属性，以缩短初始响应时间.

添加此操作后，名为 SetAppPoolLoadUserProfileTrue 的现有 CA 停止工作.此 CA 强制站点上的该设置为 true，即使计算机上的默认站点已更改，因此此设置为 false，所以我们确实需要它来工作.

当操作失败时，日志文件包含以下行.

MSI (s) (A0:18) [15:02:43:639]:执行操作:ActionStart(Name=SetAppPoolLoadUserProfileTrue,,)行动 15:02:43:SetAppPoolLoadUserProfileTrue.MSI (s) (A0:18) [15:02:43:641]:执行操作:CustomActionSchedule(Action=SetAppPoolLoadUserProfileTrue,ActionType=3073,Source=BinaryData,Target=SetAppPoolLoadUserProfileTrue,CustomActionData=AppPoolName=xxxxx)MSI (s) (A0:18) [15:02:43:670]:为线程 50712 创建类型为 790536 的 MSIHANDLE (377)MSI (s) (A0:C8) [15:02:43:670]:调用远程自定义操作.DLL:C:WindowsInstallerMSIBD82.tmp，入口点:SetAppPoolLoadUserProfileTrueCustomAction SetAppPoolLoadUserProfileTrue 返回实际错误代码 1154(请注意，如果翻译发生在沙箱内，这可能不是 100% 准确)MSI (s) (A0:C8) [15:02:43:673]:为线程 50712 关闭 790536 类型的 MSIHANDLE (377)MSI (s) (A0:18) [15:02:43:674]: 注意: 1: 1723 2: SetAppPoolLoadUserProfileTrue 3: SetAppPoolLoadUserProfileTrue 4: C:WindowsInstallerMSIBD82.tmp错误 1723.此 Windows 安装程序包有问题.无法运行完成此安装所需的 DLL.请联系您的支持人员或软件包供应商.操作 SetAppPoolLoadUserProfileTrue，条目:SetAppPoolLoadUserProfileTrue，库:C:WindowsInstallerMSIBD82.tmpMSI (s) (A0:18) [15:20:25:139]:产品:xxxxxxx -- 错误 1723.此 Windows 安装程序包有问题.无法运行完成此安装所需的 DLL.请联系您的支持人员或软件包供应商.操作 SetAppPoolLoadUserProfileTrue，条目:SetAppPoolLoadUserProfileTrue，库:C:WindowsInstallerMSIBD82.tmp操作于 15:20:25 结束:InstallFinalize.返回值 3.

这看起来像是从 PE 中提取 dotnet PE 以执行此操作的问题.二进制文件中的所有其他 CA 都可以正常工作，包括新的.

解决方案

同样的事情发生在我身上.galets"已经指向正确的方向，让我走上正轨(抱歉，没有代表支持).

短版:

MakeSfxCA 生成的本机 dll 不遵循导致观察到的行为的 PE/COFF 规范.

长版:

1. 构造一个 CA，例如HavocAction"，具有三个导出的入口点(即标有CustomAction"属性)，命名为HavocEntryPointa"、HavocEntryPointB"、HavocZappEntryPoint"(注意准确的拼写).这些方法可能只返回ActionResult.Success".
2. 想出简单的设置，a) 只调用HavocEntryPointa"，b) 只调用HavocEntryPointB"
3. ==> 设置a)"将起作用，设置b)"将失败
4. 取消注释HavocZappEntryPoint"上的CustomAction"属性，行为反转，即
5. ==> 设置a)"将失败，设置b)"将起作用

进一步分析

当您转储包装好的 CA.dll 文件时

dumpbin/Exports HavocAction.CA.dll

你会得到类似(摘录)

125 7C 00003A36126 7D 00003A4C HavocEntryPointa127 7E 00003A62 HavocEntryPointB128 7F 00003A78 HavocZappEntryPoint129 80 000042FC zzzEmbeddedUIHandler130 81 000043B8 zzzInitializeEmbeddedUI131 82 0000467F zzzShutdownEmbeddedUI132 83 00003AA5 zzzzInvokeManagedCustomActionOutOfProcW

这是错误的(搜索pecoff_v83.docx"，参见导出的 DLL 函数未按词法排序?).条目应该被排序(按 ASCII)，以便在从 dll 加载方法时进行二进制搜索(条目HavocEntryPointa"和HavocEntryPointB"互换).

我有根据的猜测是，当从 dll 加载代码时，二进制搜索会失败，从而导致错误.由于二分搜索的性质，删除HavocZappEntryPoint"会反转效果.

关于OP的备注

Kjartan首先使用了SetApplicationAutoStart"和SetAppPoolLoadUserProfileTrue"，由于排序错误，没有正确导出到CA.dll；大写字母P"出现在小写字母l"之前，但这已被 MakeSfxCA 互换.他的后一个选择ConfigureApplicationAutoStart"和SetAppPoolLoadUserProfileTrue"的排序符合PE/COFF规范.

PS:现在是 http://wixtoolset.org/issues/4502.p>

更新

PPS:从 WiX 3.9 RC3 版本开始，包含此问题的错误修复；一切都按预期进行.

I have a Custom Action project that has various CA's used by installers that my company creates, a few of those are used to manipulate the IIs7 through the Microsoft.Web.Administration API.

I added a new custom action called SetApplicationAutoStart the the class containing IIs related CA's. This custom action is used to set the autoStart attribute that forces the IIs to preload and start WCF services so that initial response time will be shorter.

After adding this action an existing CA called SetAppPoolLoadUserProfileTrue stopped working. This CA forces that setting on a site to true, even if the default site on the computer has been changed so that this setting is false, so we really need it to work.

The log files contains the following lines when the action fails.

MSI (s) (A0:18) [15:02:43:639]: Executing op: ActionStart(Name=SetAppPoolLoadUserProfileTrue,,)
Action 15:02:43: SetAppPoolLoadUserProfileTrue. 
MSI (s) (A0:18) [15:02:43:641]: Executing op: CustomActionSchedule(Action=SetAppPoolLoadUserProfileTrue,ActionType=3073,Source=BinaryData,Target=SetAppPoolLoadUserProfileTrue,CustomActionData=AppPoolName=xxxxx)
MSI (s) (A0:18) [15:02:43:670]: Creating MSIHANDLE (377) of type 790536 for thread 50712
MSI (s) (A0:C8) [15:02:43:670]: Invoking remote custom action. DLL: C:WindowsInstallerMSIBD82.tmp, Entrypoint: SetAppPoolLoadUserProfileTrue
CustomAction SetAppPoolLoadUserProfileTrue returned actual error code 1154 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (A0:C8) [15:02:43:673]: Closing MSIHANDLE (377) of type 790536 for thread 50712
MSI (s) (A0:18) [15:02:43:674]: Note: 1: 1723 2: SetAppPoolLoadUserProfileTrue 3: SetAppPoolLoadUserProfileTrue 4: C:WindowsInstallerMSIBD82.tmp 
Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor.  Action SetAppPoolLoadUserProfileTrue, entry: SetAppPoolLoadUserProfileTrue, library: C:WindowsInstallerMSIBD82.tmp 
MSI (s) (A0:18) [15:20:25:139]: Product: xxxxxxx -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor.  Action SetAppPoolLoadUserProfileTrue, entry: SetAppPoolLoadUserProfileTrue, library: C:WindowsInstallerMSIBD82.tmp 
Action ended 15:20:25: InstallFinalize. Return value 3.

This looks like a problem extracting the dotnet PE from the PE for this action. All other CA's in the binary work properly including the new one.

解决方案

Same thing happened to me. "galets" was already pointing in the right direction, setting me on track (no rep to upvote, sorry).

Short version:

MakeSfxCA produces native dlls not following the PE / COFF spec leading to the observed behaviour.

Long version:

1. Construct a CA, e.g. "HavocAction", having three exported entry points (i.e. marked with "CustomAction" attribute), named "HavocEntryPointa", "HavocEntryPointB", "HavocZappEntryPoint" (mind the exact spelling). The methods may just return "ActionResult.Success".
2. Come up with simple setups, a) invoking just "HavocEntryPointa", b) invoking just "HavocEntryPointB"
3. ==> Setup "a)" will work, Setup "b)" will fail
4. Uncomment the "CustomAction" attribute on "HavocZappEntryPoint" and the behaviour is inverted, i.e.
5. ==> Setup "a)" will fail, Setup "b)" will work

Further analysis

When you dump the wrapped CA.dll-file with

dumpbin /Exports HavocAction.CA.dll

you get something like (excerpt)

125   7C 00003A36 
126   7D 00003A4C HavocEntryPointa
127   7E 00003A62 HavocEntryPointB
128   7F 00003A78 HavocZappEntryPoint
129   80 000042FC zzzEmbeddedUIHandler
130   81 000043B8 zzzInitializeEmbeddedUI
131   82 0000467F zzzShutdownEmbeddedUI
132   83 00003AA5 zzzzInvokeManagedCustomActionOutOfProcW

This is wrong (search for "pecoff_v83.docx", cf. Exported DLL functions not ordered lexically?). The entries are supposed to be sorted (by ASCII) in order to do a binary search when loading methods from the dll (the entries "HavocEntryPointa" and "HavocEntryPointB" are interchanged).

My educated guess is, when loading code from the dll the binary search fails, resulting in the error. Due to the nature of a binary search, removing "HavocZappEntryPoint" inverts the effect.

Remark regarding OP

Kjartan first used "SetApplicationAutoStart" and "SetAppPoolLoadUserProfileTrue" which was not correctly exported to the CA.dll due to wrong ordering; the upper case letter "P" comes before the lower case "l" but this was interchanged by MakeSfxCA. His latter choice "ConfigureApplicationAutoStart" and "SetAppPoolLoadUserProfileTrue" is ordered conforming to the PE / COFF spec.

PS: This is http://wixtoolset.org/issues/4502 now.

Update

PPS: Starting with the WiX 3.9 RC3 release the bug fix for this issue is included; everything works as expected.

这篇关于向项目添加新的自定义操作会阻止运行现有的自定义操作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！