我有一个应用程序，它包含 2 个网站、3 个 Windows 服务（其中 2 个托管 WCF 服务）和 3 个 SQL 数据库。
很可能所有系统都将安装在 1 或 2 台服务器上，但也可能会将某些服务安装在不同的机器上，如果它们会严重影响性能的话。
我需要为所有这些员工创建 WIX 安装程序。问题是我不确定创建单个复杂的安装程序是否会更好，该安装程序将能够安装任何组件集（可能安装某些服务），或者几个单独的安装程序。
如果整个产品安装在同一台机器上，单安装程序方法具有重要优势 - 我们只需要向用户显示几个对话框，我们将能够自动设置组件之间的连接配置。但是当然这种安装程序的开发是非常复杂的：安装程序向导页面应该根据功能显示，当前安装在机器上。将有多种条件，测试所有条件将是地狱。
多安装程序方法更易于实施和测试。但当然，用户安装产品会更难——他需要多次设置相同的服务安装 URL（每个安装程序一次）——设置 WCF 服务的连接配置。
我搜索了该领域的最佳实践，但似乎没有很多信息。有人可以建议哪种方式更合适吗？
如果设计正确，您可以在两种方法之间来回切换。就我个人而言，我使用了 InstallShield，它具有称为 RELEASE 标志和产品配置的功能。它基本上是一种定义多个构建的方法，这些构建引入不同的功能并应用不同的品牌（ProductName、ProductVersion、ProductCode、UpgradeCode、INSTALLDIR 等等。）这就是你如何制作多个单一产品安装然后再次构建它作为产品系列套件。这种模式非常适用于 SOA。同样的事情可以在 WiX 中使用预处理器语句来控制编译。
我曾经在一家生产基于 SOA 的服务器产品的公司工作。该系统有 5 个类别的 26 个安装程序（Win 客户端、移动客户端、服务层、Web UI 层和 SSRS 报告），我将每个安装程序作为它自己的安装程序进行，它确实有助于降低复杂性。每个服务都有自己的数据库，这使得编写 SQL 脚本来创建和更新数据库变得更加容易。它还减少了每次安装必须执行的配置量，因为它只需要知道如何设置自己以及与之通信的其他部分。
将所有这些部分组合在一起的引导程序可能需要也可能不需要。我们选择 SOA 的部分原因是让我们完全控制如何扩展系统。这种类型的灵活性（1 台服务器上 26 件，26 台服务器上 1 件，2 层，3 层，n 层）使得通过简单的向导 UI 封装变得困难。
我提供了第二个答案，以给出与我的第一个不同的观点。Microsoft Team Foundation Server 安装是针对不同角色的 1 个单一安装程序。您可以横向扩展系统的各个层，但安装都是一样的：全部安装。
他们选择的是投资一个角色配置向导，该向导在安装后执行以激活给定的已安装功能并配置它的设置以及它需要与之通信的下一层的设置。
这也是一个非常好的方法。
我会使用多个安装程序，捆绑到一个大的单个安装程序中，这使您可以轻松地分离和测试它们。捆绑安装程序的目的是一次性捕获用户的数据并将其传递给所有选择安装的安装程序。
您可以使用来自 Wix 的 Burn 支持或其他设置创作工具（为您提供 GUI，让您可以轻松地创建项目和对话框）来执行此操作。Wix 是一个非常好的工具，但是与提供和拖放 IDE 以设计对话框并链接安装单独的安装的良好设置创作工具的许可证成本相比，创建项目所需的时间太多了安装程序。
编辑
将值从引导程序传递给后台安装程序非常容易，您无需编写任何自定义代码。这是直接从设置创作工具处理的。您需要做的就是确保该工具能够创建符合 Windows Installer 的程序包。这样，您可以在安装程序的命令行中将用户所做的选择作为属性值传递给后台安装程序。
引导程序安装程序不应注册到 Windows 安装程序，因此它不会出现在控制面板中，作为单独的应用程序，您应该只看到单独的后台安装程序。