我们需要在我们的服务器上安装大约4-5个供应商MSI（我们正在讨论接近50k的机器）。在安装过程中，我们需要根据运行它的机器传递大量属性。
我已经整理了一个WIX Bundle包，它从Registry中读取它需要的属性，并且为了编写Registry值，我创建了一个C＃控制台应用程序。因此部署的最终输出将是3个文件（控制台应用程序，控制台app.config，wix_bundle.exe）。我没有为此创建任何自定义引导程序，只是使用此应用程序的默认引导程序。
现在另一个处理相同6MSI的小组已经提出了一个VBScript来安装Vendor Msi。他们还编写了管理升级/补丁等的逻辑。我们需要做出决定继续前进，我想知道这方面的利弊。我会提到我的想法，如果错了，请加上或纠正我。
AM不支持或反对任何解决方案，但我需要确保解决方案可以持续多年。我们将至少使用它5到10年。
非常感谢任何帮助！
WIX捆绑的优点 1.所有MSI都组合在一起作为单个实体，因此与VBScript相比，卸载非常简单。 2.我们有一个与WIX Bundle相关的版本，而不必找到单个MSI的版本。 3.控制台应用程序控制编写WIX-Bundle所需的属性，因此服务帐户/密码等具有某种抽象。
WIX BUndle的缺点 1.我不确定它将如何处理补丁和升级。我看到很多帖子都说他们在wix bundle中看到补丁/升级的问题。 2.通过注册表读取参数并不是最好的解决方案。如果我可以将属性作为命令行传递给WIX包，那会更好。我明白我必须为此编写一个自定义引导程序？ 3.
VBScript的优点 至少在我们的案例中，使用VBScript的解决方案是有效的，不需要额外的工作。 2.
VbScript的缺点 1.在安装过程中，我们使用多个服务帐户，这些服务帐户会根据计算机进行更改，但在VB脚本中，所有这些帐户（基于每台计算机）以及密码都是硬编码的。 2.维护脚本，因为它具有使用GUID /版本号等的卸载/升级/补丁等逻辑。我们需要为每个版本手持/更新vbscript以确保它正常工作。
答案 0 :(得分：3)
我会使用Burn。它创建了一个围绕所有必需软件包的“身份”，您可以识别，升级，添加，修补等.Burn处理软件包的升级和补丁，Visual Studio 2012将其用于所有产品，补丁和VS更新。如果有问题，我希望看到他们打开错误。 ：）
此外，wixstdba允许您通过设置刻录变量的命令行指定属性，请参阅WixBalExtension中的Overridable扩展名属性。您不需要自定义BA来支持该功能。
Bundle的另一个优点是，如果MSI失败，Burn将尝试回滚以使机器再次处于良好状态。您可以控制回滚通过RollbackBoundary元素的距离。