WiX 3.0在通过持续集成执行时​​抛出错误217

67

这是我们的Windows 2008自动构建套件在运行ICE时（从WiX 2.0迁移到WiX 3.0后）引发的错误：

LGHT0217：执行ICE操作'ICE01'时出错。此类ICE故障的最常见原因是注册脚本引擎错误。有关详细信息以及如何解决此问题，请参见http://wix.sourceforge.net/faq.html#Error217。外部UI消息记录器不期望以下字符串格式：“无法访问Windows Installer服务。如果未正确安装Windows Installer，则可能发生。请与支持人员联系以寻求帮助。”。在light.exe（0，0）中

此外，这些是事件日志中显示的错误：

MSIInstaller：无法连接到服务器。错误：0x80070005产品：[ProductName]-错误1719。无法访问Windows Installer服务。如果未正确安装Windows Installer，则会发生这种情况。请与您的支持人员联系以获得帮助。

直观地：

  • VBScript和JScript在admin下注册。
  • 集成服务具有桌面交互和所有文件的权限
  • 当其他用户甚至以集成帐户身份（通过RDP）登录的用户在同一台​​机器上手动执行时，构建成功

到目前为止，我还没有主意。

如何在保持ICE验证的同时解决此问题？

continuous-integration  wix  build-automation  wix3 
— 里纳特·阿卜杜林（Rinat Abdullin）
source
7
太棒了，错误消息中的FAQ网址已损坏...
— LockTar 2014年

Answers:

48

故事的结尾：

在没有任何运气的情况下摆弄了集成帐户，DCOM和服务激活等权限之后，我最终只是在连续集成版本中禁用了ICE验证，同时仍将其保留在本地版本中。

要禁用ICE验证，可以在.wixproj文件中将SuppressValidation设置为true：

    <PropertyGroup>
        <SuppressValidation>true</SuppressValidation>
    </PropertyGroup>

或将-sval命令行选项传递给light.exe。

— 里纳特·阿卜杜林（Rinat Abdullin）
source
1
您如何禁用ICE验证的？
— bugfixr 2011年
8
那不是一个真正的答案，而是一个不是很好的解决方法。
— 卡斯珀·莱昂·尼尔森
4
也许这不是一个好的解决方法，但这是我发现生成MSI的唯一方法。因此，谢谢Rinat！
— schglurps 2012年
9
对于其他人考虑这个答案是一个可行的解决方案，你应该明白，违反ICE能带给你在试图坚持f.ex烦恼msdn.microsoft.com/en-us/library/windows/desktop/... 以及生产上现场正式检查。简而言之。不要通过禁用ICE检查来解决您的问题。
— 卡斯珀·莱昂·尼尔森
1
无需强制验证。检查我的答案下3个帖子。
— Ognyan Dimitrov 2013年
31

将TFS生成控制器帐户添加到本地管理员组并重新启动Windows服务为我完成了这项工作。

— 卡斯珀·莱昂·尼尔森
source
1
但这违反了团队建设的最佳做法，请参阅：msdn.microsoft.com/en-us/library/dd578625
— jessehouwing 2012年
11
我同意这是一种不好的做法，不是我个人喜欢做的事情，但这是两种弊端中的一种。完全禁用您的MSI的ICE验证，而不是使构建帐户成为管理员。
— 杰夫·温
为了进一步反映@Jeff的评论，它的确是一个显而易见的选择：花时间在内部网上正确地保护构建计算机的安全，或者禁用可能破坏诸如“专为Windows Server设计”徽标验证之类的检查。
— 卡斯珀·莱昂·尼尔森
4
知道需要什么确切权限而不是授予完整的管理员角色将非常棒...
— Ivan
1
在我的公司中，不允许这样做。正如伊万（Ivan）上文所述，有人知道需要哪些确切权限吗？（顺便说一句，我们暂时尝试了此建议的解决方案，并且奏效了）
— donttellya 2014年
27

我找到了根本原因。我尝试了发现的所有内容，包括类似于Re：[WiX-users] light.exe中发布的自定义验证程序扩展名的运行ICE时随机失败。。

这不是各种线程中建议的并发问题。这是由于过大的流程环境块（PEB）引起的。

事实证明Windows Installer无法处理大于32 kB的进程环境块。在我的环境中，由于构建系统设置的变量数量及其大小（例如，包含多个重复值的PATH变量），PEB约为34 kB。

有趣的是，根据环境变量，Windows XP和2003的PEB硬限制设置为32 KB。这可能会在构建的早期阶段导致易于捕获的构建中断。较新的Windows没有此限制，但是我猜Windows Installer开发人员将其内部环境缓冲区限制为32 kB，并且在超过该值时会优雅地失败。

该问题很容易重现：

  • 创建一个.bat文件，该文件设置大小超过32 kB的环境变量。例如，它可以是32行set Variable<number>=<text longer than 1024 characters>
  • 启动cmd.exe
  • 执行您创建的批处理文件
  • 在同一cmd.exe窗口中：
    • 尝试在Wi上使用带有ICE验证的WiX构建MSI软件包，或者
    • 运行smoke.exe以验证您的包裹，或
    • 只需运行 msiexec /i Package.msi
  • 以上所有命令最终将报告Error 1719 - Windows Installer could not be accessed。

因此，解决方案是-查看构建脚本并减少环境变量的数量和大小，以使它们都适合32 kB。您可以通过运行以下命令轻松验证结果：

set > environment.txt

目标是使文件 environment.txt小于约30 kB。

— 今木
source
这似乎也是我遇到的问题。我怀疑并发，但是并行构建的MSI不够。非常感谢您分享此解决方案。很想知道您最终如何调试它。
— kreinsch 2013年
10
我认为您的意思是造成此问题的原因之一，因为我的环境变量小于2K。
— 乔尔·麦克贝斯
也为我工作，谢谢。但是我的门槛较低。6KB（-> 5900个字符）有效。10 KB（-> 9300个字符）显示错误。在electronic-builder 20.39.0中的Windows Server 2016上运行
— KeKru
我的environment.txt是〜7 KB。因此，这可能不是问题。🤔–
— 马提尼·比安科
1
也为我工作：我使用的电子生成器使用CSC_LINK带有base64编码证书的变量，导致环境太大。为了解决这个问题，我将证书存储在文件中并设置CSC_LINK为证书文件名。
— sduthil
5

imagi完全正确！我不敢相信这是真正的答案。取消验证并让TFS用户成为管理员不是一个好的解决方案。另外，我找不到NT \ Authority可以将其添加到Administrators组中，并且完全陷于此。

我在Windows Server 2012数据中心上遇到与构建代理相同的错误。解决问题：

  1. 项目清单
  2. 转到构建代理机器上的环境变量
  3. 创建两个系统变量
  4. "PF86" 等于 "C:\Program Files (x86)"
  5. "PF" 等于 "C:\Program Files"
  6. 它们之所以这么短是因为我想保存字符。我使它们没有最后的反斜杠是因为TEMP，TMP和其他字符如此制作，因此我决定对这些变量坚持使用MS标准。
  7. 通过替换每一个编辑PATH变量"C:\Program Files (x86)"有%PF86%一位"C:\Program Files"与%PF%
  8. 关闭并建立并享受！
  9. 它为我工作。:)

UPDATE 我找到了一个更好的解决方案：Rapid Environment Editor将为您完成所有这些甚至更多工作。自动地。

— 奥格扬·迪米特洛夫（Ognyan Dimitrov）
source
2

来自http://wix.sourceforge.net/faq.html#Error217：

在WiX v3中， 每次成功构建后，Light都会自动运行验证 -Windows Installer内部一致性评估程序（ICE）。验证是捕获可能导致服务问题的常见创作错误的好方法，这就是为什么现在默认运行它的原因。不幸的是，Windows Vista和Windows Server 2008上发生了一个常见问题，可能导致ICE失败。有关原因及其解决方法的详细信息，请参见 Heath Stewart的Blog 和 Aaron Stebner的WebLog。

— 格雷格马克
source
1
该链接中的任何内容实际上是否可以帮助您解决此问题？
— bwerks 2010年
9
那对我没有用。我有一个带有2008 R2 x64的全新服务器，该dll是在HKLM而不是HKCU下注册的。
— Jonesie 2011年
这些链接都已消失。请在答案中包括实际的假定解决方案。
— Kissaki '20
2

我遇到了同样的ICE错误，但问题变成Windows Installer服务已损坏。该解决方案为我工作：http : //support.microsoft.com/kb/315353

  1. 以管理员身份登录到您的计算机。
  2. 单击开始，然后单击运行。
  3. 在“打开”框中，键入cmd，然后单击“确定”。
  4. 在命令提示符下，键入msiexec.exe / unregister，然后按Enter。
  5. 键入msiexec / regserver，然后按Enter。
  6. 重新启动Windows

此外，请验证SYSTEM帐户对Windows注册表中的HKEY_CLASSES_ROOT配置单元具有完全控制访问权限。在某些情况下，您可能还必须添加管理员帐户。

— 弗拉基米尔·德米列夫
source
2

我遇到了同样的问题，并且不想抑制ICE验证。我的设置：我使用自己的计算机作为Visual Studio Online（VSO）上的构建代理。我的解决方案是更改用于在我的计算机上运行服务的帐户。不用使用网络服务或本地服务，我只是使用拥有所有必要权限的我自己的帐户登录该服务。

— 纳斯
source
这正是我发生的事情。运行构建服务的帐户存在权限问题。我更改了用户，现在构建通过了
— Dhruv Patel
这对我有用！
— Mr00Anderson
1

我有一些建议。

  • 尝试更新构建服务器上的Microsoft Installer版本
  • 请确保您使用的是WiX 3.0的最新版本，因为它的3.0版本现已稳定。
  • 如果所有其他方法均失败，请尝试在特定的构建用户下运行构建服务，您可以使用该用户来获取以下权限：
— 克里斯托弗·卡珀
source
1.是；2.最新；3.我可以更改集成帐户的权限。
— Rinat Abdullin
1
尝试将生成用户添加到DCOM本地用户组。
— Christopher Karper，2009年
那个时候没工作。我最终在集成版本中禁用了ICE验证。
— Rinat Abdullin 09年
0

转到构建计算机，然后重新启动Windows Installer服务

— 怀疑
source
0

以上建议对我都不起作用，对我而言，防病毒（mcafee）出现在图片中，看起来好像将vbscript.dll注册表项更新到了错误的DLL位置。这些是要记住的事情：

  1. 一些WiX ICE验证是使用VBSCRIPT实现的。
  2. 因此，在编译MSI时，构建服务器将需要访问c：\ windows \ system32 \ vbscript.dll。
  3. 可能是由于某种原因，运行您的构建的用户失去了对此DLL的访问权限。
  4. 如上述答案中所述，请确实寻找管理员访问权限/注册表访问权限，并确保您的用户具有该权限。

以下是我为解决此问题而采取的步骤：

  1. 在构建代理计算机上打开cmd（以admin身份运行）。
  2. 运行RegEdit
  3. 选择根目录，然后单击ctrl + f并搜索以下注册表项：{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
  4. 查找InprocServer32 \ Default密钥

在此处输入图片说明

  1. 在我的构建代理上，该路径已替换为mcafee DLL位置。我将路径更新回c：\ windows \ system32 \ vbscript.dll
  2. 编辑注册表项并不容易，因为它是受保护的注册表项。我使用下面的链接来更改访问权限，然后才能编辑该属性：编辑受保护的注册表项

更新路径后，一切都照常开始工作。

— 以赛亚书4110
source
0

我的解决方案类似于弗拉基米尔的解决方案。我的CI用户是计算机的管理员。

但是必须执行以下步骤才能使我的詹金斯构建成功：

  • 使用rdp以CI用户身份登录
  • 打开一个DOS命令提示符
  • 执行：％windir％\ system32 \ msiexec.exe / unregister
  • 执行：％windir％\ system32 \ msiexec.exe / regserver

那我就成功了

— Mumrah81
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.