由于当我们的构建过程被设计和实现(并且已经成功了几年)时我不是我公司的一部分,我发现有些东西正在被完成,可能会被看到对MSI'纯粹主义者'的'黑客攻击'。但是,为了使用Visual Studio 2012获得可行的安装程序,我一直在尽力模仿Visual Studio 2010中.vdproj
文件的操作。在我击中的许多障碍中,这个似乎是我无法解决的最后一个障碍。
作为使用Visual Studio 2010构建流程的一部分,我们构建了代码并在一个VM上创建了一个Framework MSI。然后我们使用该框架MSI并将其安装在不同的VM上。安装框架后,我们构建了产品代码并创建了一个产品MSI。这创建了Product对我们框架的依赖。这意味着当在客户端计算机上安装时,引导程序需要先安装Framework,然后再安装Product。在卸载时,我们的文档要么通过ARP或命令行“msiexec /x {Product.msi/@ProductCode}
”处理,然后是“msiexec /x {Framework.msi/@ProductCode}
”。
当时,管理层确定ProductCode
是其他产品团队确定我们的产品是否已安装在计算机上的最简单方法。这导致他们决定他们需要为框架和产品保持静态ProductCode
。
为了处理升级,他们必须创建一个ProductTool.exe
,它只不过是一个包含在/ProductCode={@ProductCode}
参数的可执行文件中的msiexec。
作为我们的引导程序的一部分,他们打电话给:
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文件具有Property的设置,但Burn似乎会覆盖它。
答案 0 :(得分:1)
不,今天Burn引擎不支持此功能。 Burn非常小心地控制REINSTALLMODE
以正确处理升级和修复。在a
中使用REINSTALLMODE
远非最佳做法,因此不受支持。此外,还不清楚为什么在您描述的场景中需要a
。