我正在筛选现有的问题，但我发现没有一个问题能在这个基本层面上明确回答这个问题。我在记事本中构建 WXS 文件，而不是从 IDE 中构建。
我的场景是：我有多个应用程序使用一些相同的程序集。这些程序集通过 exe 安装到各个应用程序文件夹中，因此它们不会相互共享。它们可能是不同的版本。文件夹看起来像：
App1：main1.exe、1.dll、2.dll
应用程序2：main2.exe，1.dll
应用程序3：main3.exe、1.dll、2.dll
我正在模板化我的 WXS 文件，但在深入之前，我想弄清楚是否可以跨应用程序复制/粘贴组件元素。
App1.wxs：
<Component Id='AudioLibrary' Guid='1111-1111111-1111111-11111' Win64='yes'>
<File Id='AudioDLL' Source='1.dll' KeyPath='yes' />
App2.wxs
<Component Id='AudioLibrary' Guid='1111-1111111-1111111-11111' Win64='yes'>
<File Id='AudioDLL' Source='1.dll' KeyPath='yes' />
这两个条目在不同应用程序的升级/卸载操作中会相互干扰吗？
通常，数据库结构允许这种类型的复制，因为父级将是唯一的产品 GUID。但我看到很多人抱怨 MSI 一定是在 70 年代写的，当时每个人都喝得酩酊大醉。因此，在我浪费时间构建一切之前，先检查一下我是否正在为失败做好准备。
编辑：我还想将其应用于 SQL 脚本组件；我可以将代码片段复制/粘贴到任何 wxs 文件中，而不必为其生成新的 GUID 吗？
组件 GUID 和绝对路径：请阅读这个旧答案：何时更改组件 GUID。本质上，绝对路径和组件 GUID 之间存在 1:1 的关系。如果更改文件名或安装到其他文件夹，则必须创建新的组件 GUID。因此，如果您将所有产品安装到同一文件夹，则应为安装的产品使用相同的组件 GUID。如果您将每个产品安装到新文件夹，它们应该具有不同的组件 GUID。
合并模块：共享组件通常通过合并模块安装。就我个人而言，我更喜欢 WiX 包含文件而不是合并模块这一概念。
WiX 包含文件：WiX 包含文件的前提是您可以在其自己的源中声明一组组件，然后包含在任意数量的设置中 - 就像 C++ 头文件一样。如果您让组件 GUID 自动生成，您应该能够在不同的 MSI 文件中包含相同的 WiX 包含文件，并且逻辑将负责为组件生成新的 GUID 或根据组件上的位置使用相同的 GUID。他们的目标磁盘。 我还没有测试过这个。 这是 Rob Mensching 本人对自动 GUID 概念的介绍。
链接：
我忘了回到这个……抱歉。
通过阅读 Stein Åsmul 的链接，我确定解决方案是根本不提供 GUID。
我不确定这是因为它是分层的，并且它继承了父GUID，还是只是生成并分配了新的GUID。如果是后者，如果您正在做补丁，那么“可能”会成为问题，因此请进行额外的研究。然而，就我而言，当我构建并运行新的安装程序时，MSI 会毫无问题地复制旧组件。它说“准备删除旧版本”，所以请预先警告。对我来说这并不重要。 我的节点有 UpgradeCode=THEGUID。组件是不言自明的，我的模板 wxs 包含这三个和其他一些组件。这为我提供了一个功能齐全的模板，我只需要替换一些变量值并删除项目不需要的组件。
<Component Id='MainExecutable' Guid='*' Win64='yes'>
<File Id='AppEXE' Source='$(var.ProductName).exe' KeyPath='yes' />
<File Id='AppPDB' Source='$(var.ProductName).pdb' Hidden='yes'/>
</Component>
<Component Id='CoreLibrary' Guid='*' Win64='yes'>
<File Id='CoreDLL' Source='Core.dll' KeyPath='yes' Hidden='yes'/>
<File Id='CorePDB' Source='Core.pdb' Hidden='yes'/>
</Component>
<Component Id='AudioLibrary' Guid='*' Win64='yes'>
<File Id='AudioDLL' Source='Audio.dll' KeyPath='yes' />
<File Id='AudioPDB' Source='Audio.pdb' />
</Component>