问题标签 [wix3.5]

我正在尝试使用在Windows Server 2008 R2上运行的TFS 2010将 WiX 集成到我的自动构建解决方案中。一切似乎都很容易，然后我得到了这个：

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

这很奇怪。但是，嘿！他们提供了一个链接。那应该有帮助，对吧？

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

一点也不。这些帖子只是描述了涉及脚本引擎注册的情况，而他们描述的情况并不存在。但是，我遇到了回复：（WiX 用户）为什么从服务帐户构建 ICE 失败？(2010-01-14) 这似乎表明如果我使用域帐户来运行 Windows Installer 服务，它将起作用。听起来值得一试。

“无论出于何种原因，在 Windows 2008（我没有测试 Vista、XP、2003、7 或 2008 R2）上，MSI 服务只能从具有管理访问权限或“交互式”登录的登录中获得。从没有管理权限的服务帐户无法访问 msi 服务，因此无法运行 ICE 测试。”

但是，当尝试使用我的构建服务帐户启动 Windows Installer 服务时：

Windows 无法在 SKILLET-1 上启动 Windows Installer 服务。错误 1297：服务帐户配置中不存在服务正常运行所需的权限。您可以使用服务 Microsoft 管理控制台 (MMC) 管理单元 (services.msc) 和本地安全设置 MMC 管理单元 (secpol.msc) 来查看服务配置和帐户配置。

好的，Windows，所以你告诉我我的构建服务帐户缺少启动服务所需的一些模棱两可的权限。使其成为管理员应该解决这个问题吗？不，这也不起作用。

因此，我将 Windows Installer 服务帐户恢复到本地系统。这次我将构建服务设置为本地管理员，瞧，成功了！不过，这几乎不是一个解决方案。

我的下一个想法是尝试隔离构建服务完成此操作实际需要的权限集。这将是一个很好的解决方案，而不必向管理员集添加更多帐户。第 1 步：进入本地安全策略并将构建服务帐户添加到当前授予管理员的所有权限。从理论上讲，这应该允许构建成功，并且从那里我可以有选择地删除权限，直到我隔离了所有必须持有的权限才能使其成功。

不幸的是，即使拥有所有相同的权限，除非构建服务帐户是本地管理员的成员，否则构建仍然会失败。为什么是这样？除了 LSP 之外，还有哪些其他东西依赖于管理员组，我可以更改这些依赖项以使我的构建服务帐户与管理员等效？

当前结论：构建服务必须是管理员才能避免 ICE 验证错误。

开放式问题：

• 为什么我的权限隔离想法不起作用？
• Error 1297以域用户身份运行 Windows Installer 服务时抛出的这个神秘现象是什么？我几乎找不到任何文档。

我正在使用 Vs2010 和 Wix 3.6.0917.0，作为记录。我在 .wixproj 文件中经常使用 $(SolutionDir) 属性，因为我只将安装程序构建为解决方案构建的一部分或团队构建的一部分，而不是单独构建。但是，虽然从命令行构建工作得很好（无论是从桌面上的 cmd 还是在构建代理上构建时），当我尝试将 .wixproj 文件重新加载到 IDE 时，我都会收到错误，因为所有 $(SolutionDir) 变量正在解析到项目目录，而不是解决方案目录。考虑：

C:\workspace\projectCollection\teamProject\branch\solution.sln C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj

并假设一个共享的自定义目标文件：

C:\workspace\projectCollection\teamProject\branch\build\shared.targets

在 installer.wixproj 中引用：

<Import Project="$(SolutionDir)build\shared.targets">

命令行构建工作正常...

但是加载到vs2010，你会看到......

The imported project "C:\workspace\projectCollection\teamProject\branch\source\installer\build\shared.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk. C:\workspace\projectCollection\teamProject\branch\source\installer\installer.wixproj

您可以在这里看到 $(SolutionDir)build\shared.targets 的解析结果是获取项目目录而不是解决方案目录。是什么赋予了？

我有一个自制的引导程序（称为 SetUp.exe），它检查目标计算机上是否安装了 .NET 3.5，如果没有，则通过运行 dotnetfx35.exe 启动安装。美好的。这适用于我需要的所有情况，Windows 2008 Server R2 除外。在此操作系统上，.NET 安装程序不会安装/启用 .NET 3.5。相反，它会弹出一个对话框，指示必须手动启用它。我更喜欢从我的引导程序 exe 或从基于 WiX 的主 MSI 中自动执行此操作。

我真的在用 WiX 苦苦挣扎。我有 .NET 程序集要安装，需要注册 COM 互操作，并且它们必须向另一个框架注册，该框架需要在 GAC 中的 .NET 程序集中调用 Register() 方法。这种注册方法是一个带有隐藏存储机制的“黑匣子”，因此我无法以声明方式执行此操作。

我知道声明性方法最适合 COM 注册，但是使用 heat.exe 时我有两个问题：

1. RegAsm 有效，但 Heat.exe 用以下消息阻塞了我的程序集：

   heat.exe：警告 HEAT5151：无法从预期为程序集的文件中收集数据：C:[...].dll。如果此文件不是程序集，您可以忽略此警告。否则，此错误详细信息可能有助于诊断故障：调用的目标已引发异常。

2. 我需要进行的二次注册依赖于 [ComRegisterFunction] 属性，该属性通常会在为 COM 互操作注册程序集时触发进一步的操作。当程序集由 RegAsm.exe 或通过调用 System.Runtime.InteropServices.RegistrationServices 注册时，通常会发生这种情况。所以，我需要我的程序集中的 ComRegisterFunction 在安装期间执行。

我不介意对 COM 注册采用声明性方法（或者我不介意是否对我的程序集进行加热），但我需要将 ComRegisterFunction 称为安装的一部分。理想情况下，我想查看我正在安装的所有可执行文件，针对具有 [ComRegisterFunction] 属性的任何方法反映它们并调用这些方法，这将在安装所有文件后完成。

如何在 WiX 中实现这一点？或者，还有其他方法吗？如果有什么不同，我将使用“Votive”Visual Studio 与项目引用的集成。

我正在迁移一些现有产品以使用 WiX 3.5（我正在使用 Votive VS 集成）。我正在安装的一些项目需要在第三方框架中注册。要求是我必须在第三方 .NET 程序集中调用 Register() 方法，以通知它我正在安装的项目的存在。它需要一个 COM ProgID。

我不知道如何让 WiX 做到这一点。我考虑过创建一个二进制自定义操作，但我找不到将参数（包含 ProgID 的字符串）传递到该自定义操作的方法。我不想硬编码它，因为我需要它是可重用的代码。我看不到以声明方式执行此操作的方法，因为 Register() 函数是一个“黑匣子”。

伙计，这是一个陡峭的学习曲线。我在这里最好的方法是什么？

我有几个正在使用 Wix 3.5 的项目，以及进展顺利的石蜡，但我一直在试图弄清楚如何在安装过程中创建 Windows 计划任务。

我可以只运行一个创建任务的 bat 文件，但我认为这不会为我提供 Wix 具有的卸载功能，也不允许我将其定义为设置 UI 的一部分。

有谁知道如何在 Wix 3.5 中创建计划任务作为 XML 配置的一部分？

我正在寻找 MSIEmbeddedChainer 和 MSIEmbeddedUI 的一些示例源代码。wix v3.0 有 <EmbeddedChainer> 命令，但没有关于如何使用的信息（或者可能不完整的实现）。我想链接我的 msis。但是，这个主题的细节很少。msi 4.5 具有非常好的特性，带有 MSIEmbeddedChainer 和 MSIEmbeddedUI。不幸的是，wix v3.0 目前似乎不支持。我看到 wix 宣布 wix burn 项目与 wix v3.6 一起启动。但我认为这个实现还有很长的路要走。

有一些开发人员使用 wpf 和 c#/c++ 为这个 MSI 链编写了自己的代码。我只是想偷偷摸摸，所以我也知道如何对它们进行编码。再次不幸的是，我没有看到任何...

有人可以帮忙吗？

所以我正在尝试在 Wix 3.5 中构建一个安装程序。

我的应用程序需要 SQL CE 3.5 才能运行。看起来 MS 的安装程序有一个简单的方法来包含它，但我不确定我需要在 WiX 中做什么。

我正在使用 Wix 3.5 Votive（Visual Studio 集成）为一些 COM 对象编写安装程序。

在 Votive 中，设置项目引用会从该项目中提取二进制文件，并在编译时自动生成 Wix 源。这绝对很棒，它是 DRY，意味着我不必经常更新 Wix XML。Votive 生成​​的片段如下所示：

它对我没有使用的源文件、文档和卫星执行相同的操作。但是，它没有为 COM 注册生成注册表实体（程序集标记为“COM Visible”和“Register for COM Interop”，但 Votive 似乎没有处理该问题的机制。

在幕后，Votive 正在调用 Heat.exe 来收集所有这些东西，并在程序集上调用 Heat 会吐出一个包含一堆<Class .../>和<RegistryValue .../>条目的文件，这正是进行 COM 注册所需要的。果然，Heat 可以生成这些东西，只需执行一次并将输出编辑到 Wix 项目中就可以了。但是，这违反了 DRY 原则，需要手动使 Wix 项目与源代码保持同步。出于有点切题的原因，我希望在每次构建解决方案时让 Votive/MSBuild 自动执行此操作。

无论如何，我都不是 MSBuild 专家，而且我正处于使用 Wix、Votive 和 MSBuild 的巨大学习曲线上。我花了好几天才走到这一步。所以，我的问题是：有没有一种简单的方法让 Votive/MSBuild 在每次构建解决方案时生成这个 COM 注册内容？我预计对于每个引用的项目，如果设置了“注册 COM 互操作”选项，那么 Votive/MSBuild 将为该项目的输出程序集生成 COM 注册内容。有没有人做到这一点，如果是这样，请在我的大脑变成果冻之前帮我一把！

使用 WiX，在用户在编辑（文本框）控件中输入格式正确的 GUID 之前禁用页面上的“下一步”按钮的最简单方法是什么？

我希望答案是 Next 按钮控件中的 Condition 元素，但我无法弄清楚条件是什么。条件是否支持正则表达式匹配？