我正在将 InstallShield 项目转换为基于 WiX 的安装程序。我有许多 VB6 项目需要注册其二进制文件。
InstallShield 项目实际上将这些标记为自注册文件。根据我的阅读，这似乎是 Windows Installer 世界中的“坏事”。
我的问题是，那我该怎么办？每次重新编译后，VB6 项目的内部 GUID 都会发生变化——是的，我已经在使用二进制兼容性。
我已使用Heat 生成所有注册表和类条目，但其中一些条目会随着构建而变化。我读到 Heat 并非设计用于每次构建，而是用作起点。
其他人正在做什么来处理 VB6 和 WiX 注册？
【问题讨论】：
我们在 VB6 中开发了两种类型的组件。我们跨项目引用的潜在通用组件和我们每天构建的易失性应用程序组件。公共组件打包为合并模块（使用 WiX），而应用程序组件映射到应用程序设置的组件。这是我们主 .wxs 文件的 sn-p
<Component Id="MyFile15.ocx" Guid="YOURGUID-BCB7-451C-B07D-D205AEAE1EB9" >
<File Id="MyFile15.ocx" Name="MyFile15.ocx" LongName="MyFile15.ocx" KeyPath="yes" src="$(var.SrcAppBinnPath)\MyFile15.ocx" DiskId="1" />
<?include Registry_MyFile15.wxi ?>
</Component>
我们仍在使用 WiX 2.0，因此我们使用 tweaked version of tallow 为我们每天构建的所有 ActiveX DLL/OCX/EXE 生成注册表 .wxi 文件。我们将所有 COM 注册作为直接注册表项发送，而不是 com/typelib 条目。我们的目标是旧版 Windows Installer 2.0，因为我们不需要任何新功能。
我们在一些特殊情况下使用自定义操作（VC6 DLL）——MSDE 设置、数据库修补、DCOM 下载/设置。我们正在使用平台 SDK 引导程序下载 instmsiX.exe 并在原始系统（主要是 9x 和 NTs）上准备 Windows 安装程序。我们正在使用 7-zip 自解压器在客户端机器上解压引导程序和 msi。在某些情况下，我们在可执行文件上使用 UPX --lzma，但这些在终端服务器上的扩展性不是很好，在这些终端服务器上，非打包版本在会话中被重用。
最近，我们一直在使用无注册 COM 将客户迁移到可移植版本。我们正在使用我们内部的UMMM tool 来生成免注册的 COM 清单。 SxS COM 有限制（没有 DCOM，没有 ActiveX EXE），但允许我们在应用程序运行时更改构建 - 无需重新安装停机时间。
【讨论】：
我们一直在玩弄的一件事是通过使用registration-free COM 完全消除全局 COM 注册。 （我们追求的主要优势是能够在完全隔离的情况下并排部署同一应用程序的不同版本。）
但是，使用免注册 COM，您仍然必须编写或生成需要由安装程序部署的清单文件。链接问题的答案表明有一些工具可以帮助解决这个问题。
同时，我们还为旧的 VB6 和 Delphi 库使用了自注册和自动 wxs 生成与 heat.exe 的组合。虽然您说得对，热量最初并不是为那样使用而设计的，但现在moving in that direction 已经有一段时间了。
在任何情况下，标识符的稳定再生（这是 heat.exe 的初始设计中缺少的）仅在您希望支持小升级或在应用程序之间共享组件时才重要。我们只是在升级过程中完全卸载了产品的先前版本（又名 major upgrade），所以我们不需要担心这些事情。
编辑：自从 2010 年写下这个答案以来，我已经了解了有关 Windows 安装程序的一两件事。我不再相信重大升级可以让您摆脱对稳定 GUID 的需求。组件 GUID 在就地升级之间应尽可能保持稳定。重大升级并不总是与卸载+重新安装具有相同的最终结果。
【讨论】：
我走了一条不同的路线，并使用我在 IDL 中创建并编译为类型库 (.tlb) 的接口定义了我的所有对象。有点冗长的方法，但这意味着所有 GUID 无论如何都保持固定。
我能够实现接口的版本并在同一个文件中处理多个版本的 dll。
缺点是，这对 OCX 控件没有帮助，并且您不能在 tlb 边界上使用事件。这对我来说不是问题，因为我通常使用从 DLL 到调用者的回调，因为它们可以提高效率。
该产品以 DVD 形式部署给世界各地的客户，目前使用的是 InstallShield 安装程序，但我也在调查是否迁移到 WiX。
【讨论】：