1

我目前正在使用 Wise Studio 7 维护安装程序（在更改为 IS 2012 Spring 的过程中）我想要完成的是让 QA 能够在每个构建之间升级 MSI 包。不过，该公司不想更改每个版本的产品代码或版本号。我认为这可能与 PackageCode 有关，但它似乎不起作用。我收到一条消息，说产品当前已安装。也许 Wise Studio 的 dll 也妨碍了我。我不太了解它的作用。我已尝试更改其顺序和条件，使其不运行但不影响输出。

目前，我设置了升级表以防止降级。我还授权允许升级。如果我保持包代码相同，安装会在维护模式下运行，并且 QA 会使用维护对话框卸载之前的安装。但这不是真正的升级。我认为更改包代码应该允许小的更新。但显然我的理解是不正确的。也许这仅适用于补丁文件。

有什么方法可以实现我们想要的。我们真的不想增加版本号。该公司希望安装程序版本反映应用程序的发布号，而不是构建版本。当然，我们不想在构建之间将产品代码 GUID 设置为不同的值。

感谢您的任何见解。

编辑：我应该提到我们有一个持续的构建系统。

问候，丹

4

2 回答 2

2

始终测试您的服务策略。

如果您计划向客户提供重大升级，那么这就是您应该测试的。

如果您计划进行较小的升级，那么这就是您应该测试的。

我建议“公司”（臭名昭著的“他们”）不应该关心产品代码。他们可以关注 ProductVersion 的主要和次要部分，但他们不应该关注构建部分。这两件事应该保留给 CM / Install Engineering，否则它们会限制你失败。

于 2013-02-07T14:08:20.197 回答
1

您已经排除了 MSI 本身所有可能的解决方案。

  • 仅更改包代码会使您处于小更新的领域。这将限制您可以进行的更改，并且很难推断当构建无序安装时会发生什么（由您的 QA 人员；通常您不会向世界发布多个这些构建）。
  • 更改产品版本也会使您进入小升级领域。这更容易推理（并定义一个顺序），但同样具有限制性。但是，您必须更改前三个版本部分之一，而您已经拒绝了。
  • 每次构建更改产品代码都会为您带来重大升级，这很容易推理，消除了大多数限制，并且应该自动删除以前的限制。这通常是我在这里的建议，除非您需要支持的方案是从先前发布的版本进行小升级。

所以要回答的问题是：你真的需要拒绝所有基于 MSI 的解决方案吗？如果需要，你能提供一些其他的方法吗？例如，您是否可以要求 QA 在启动新版本之前运行脚本或批处理文件来删除旧版本？您能否要求 QA 将他们的虚拟机恢复到没有先前构建的状态？

于 2013-02-07T13:33:39.653 回答