3

由于在设计和实施我们的构建过程时我不是我公司的一员（并且已经成功了好几年），我发现正在做的事情可能被视为“黑客” ' 对 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 似乎覆盖了它。

4

1 回答 1

1

不，目前的 Burn 引擎不支持此功能。BurnREINSTALLMODE非常小心地控制以正确处理升级和维修。使用ainREINSTALLMODE远非最佳实践，因此不受支持。此外，尚不清楚为什么a在您描述的场景中是必要的。

于 2013-06-22T21:15:53.740 回答