我正在将InstallShield项目转换为基于WiX的安装程序。我有许多VB6项目需要注册二进制文件。
InstallShield项目实际上将这些标记为自注册文件。从我所看到的，这似乎是Windows Installer世界中的“坏事”。
我的问题是，那我该怎么办？每次重新编译后，VB6项目的内部GUID都会发生变化 - 是的，我已经在使用二进制兼容性了。
我已使用Heat生成所有注册表和类条目，但其中一些条目从构建更改为构建。我已经读过，Heat不是为每次构建而设计的，而是用作起点。
其他人正在做什么来处理VB6和WiX注册？
答案 0 :(得分：3)
我们在VB6中开发了两种类型的组件。我们在项目和我们每天构建的易变应用程序组件中引用的潜在公共组件。通用组件打包为合并模块（使用WiX），而应用程序组件映射到应用程序设置的组件。这是我们的主要.wxs文件的片段
<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下载/设置。我们正在使用Platform SDK引导程序，它可以下载instmsiX.exe并在原始系统（主要是9x和NT）上准备Windows Installer。我们正在使用7-zip自提取器来解压客户机上的bootstrapper和msi。在某些情况下，我们在可执行文件上使用UPX --lzma，但这些在终端服务器上不能很好地扩展，其中非打包版本在会话中重用。
最近我们一直在使用无reg的COM将我们的客户迁移到便携式构建。我们正在使用我们内部的UMMM tool来制作免注册的COM清单。 SxS COM有局限性（没有DCOM，没有ActiveX EXE），但允许我们在应用程序运行时更改构建 - 无需重新安装停机时间。
答案 1 :(得分：1)
我们一直在努力的一件事是使用registration-free COM完全消除全局COM注册。 （我们追求的主要优势是能够在完全隔离的情况下并排部署同一应用程序的不同版本。）
但是，对于免注册COM，您仍然必须编写或生成需要由安装程序部署的清单文件。链接问题的答案表明，有一些工具可以帮助解决这个问题。
与此同时，我们仍然使用自我注册和自动wxs生成与heat.exe混合使用旧的VB6和Delphi库。虽然你说的热量最初并没有像这样使用，但现在已经moving in that direction了一段时间。
在任何情况下，标识符的稳定重新生成（这是heat.exe初始设计中缺少的内容）仅在您希望支持次要升级或在应用程序之间共享组件时才重要。我们只是在升级过程中完全卸载了以前版本的产品（又名 major upgrade ），所以我们不需要担心这些事情。
编辑：自2010年撰写此答案以来，我已经了解了一些关于Windows安装程序的知识。我不再相信重大升级会让您免于对稳定GUID的需求。组件GUID应在就地升级之间尽可能保持稳定。主要升级并不总是与卸载+重新安装具有相同的最终结果。
答案 2 :(得分：0)
我使用不同的路径并使用我在IDL中创建的接口定义了所有对象，并将其编译为类型库（.tlb）。稍微有点啰嗦的方法，但这意味着所有的GUID都保持不变。
我能够实现接口的版本并在同一个文件中处理多个版本的dll。
缺点是，这对OCX控件没有帮助，你不能在tlb边界使用事件。这对我来说不是问题，因为我通常使用从DLL到其调用者的回调，因为它们可以更有效。
此产品在DVD上部署到世界各地的客户端，目前正在使用InstallShield安装程序，但我正在调查转移到WiX。