【发布时间】：2013-05-31 14:57:28
【问题描述】：
由于在设计和实施我们的构建过程时我不是公司的一员（并且已经成功了好几年），所以我发现正在做的事情可以查看作为MSI“纯粹主义者”的“黑客”。但是，为了获得一个可使用Visual Studio 2012 的安装程序，我一直在尽我所能模仿Visual Studio 2010 中的.vdproj 文件所做的工作。在我遇到的许多障碍中，这似乎是我无法解决的最后一个。
作为使用 Visual Studio 2010 构建过程的一部分，我们构建了代码并在一个 VM 上创建了框架 MSI。然后，我们采用了该框架 MSI 并将其安装在不同的 VM 上。安装框架后，我们构建了产品代码并从中创建了产品 MSI。这创建了对我们框架的产品依赖。这意味着当在客户端机器上安装时，引导程序需要先安装框架，然后安装产品。在卸载时，我们的文档声明要么通过 ARP 处理，要么通过命令行“msiexec /x {Product.msi/@ProductCode}”，然后是“msiexec /x {Framework.msi/@ProductCode}”。
当时，管理层确定ProductCode 将是其他产品团队确定我们的产品是否已安装在机器上的最简单方法。这导致他们决定需要为框架和产品保留一个静态的ProductCode。
为了处理升级，他们必须创建一个 ProductTool.exe，它只不过是封装在带有 /ProductCode={@ProductCode} 参数的可执行文件中的 msiexec。
作为我们引导程序的一部分，他们调用：
- 安装先决条件（Windows Installer 4.5、.NET 3.5 SP1、SQL Server 2008 R2 Express、Sync 2.1）
-
ProductTool.exe(Product.msi-- 卸载 Product.msi) -
ProductTool.exe(Framework.msi-- 卸载 Framework.msi) - 安装
Framework.msi - 安装
Product.msi
但是，直到最近我才发现Burn 引导程序不允许REINSTALLMODE=amus。在安装日志中，它表示将其更改为REINSTALLMODE=vomus。显然，为了让上述过程进行升级，他们必须设置REINSTALLMODE=amus。
更新：我终于与安装程序的原始开发人员交谈，发现REINSTALLMODE=amus 被故意用于还原所有版本化文件（程序集、DLL 文件等）和非版本化文件（.config、SQL 脚本等）作为风险最小化和稳健性/“自我修复”策略。
说了这么多，是否甚至可以使用标准的烧录引导应用程序 (BA) 设置 REINSTALLMODE=amus 以便我可以进行升级？ MSI 文件设置了属性，但 Burn 似乎覆盖了它。
【问题讨论】：