我将WiX构建MSI作为自动构建的一部分。我希望用户能够安装其中一个版本，然后能够在其上安装第二天的版本。
进行小型或重大升级，需要更改ProductVersion内的内部版本号，我认为这不是一个选项，原因如下：
首先，我能想到的唯一一个问题就是颠覆修订版或内部版本号，但这个数字溢出65,535，我们将来可能会遇到这种情况。其次，该号码已用于向客户分发错误修复版本。
因此，如果我无法更改ProductVersion，那么我唯一的选择就是Small Update。我尝试通过确保id的{{1}} package已根据revision number summary导致<Package InstallerVersion="405" Compressed="yes" InstallScope="perMachine" />元素更改documentation中的包代码而尝试实现此目的每次都会生成一个新的。
msiexec
但是，在运行MSI时会出现一个错误对话框，警告用户已安装此产品。安装它的唯一方法是将additional command line arguments传递给ProductCode，即使这似乎也没有真正重新安装组件。
更改<Product Id="*"...>自动生成ProductVersion但不更改no似乎遵循setting AllowSameVersionUpgrades到{{1}}所述的规则，这是默认设置值。这意味着Windows Installer将其视为一个单独的软件包，并将其与第一个软件包一起安装，但同样似乎不会覆盖已安装的文件，只需在已安装的程序表中添加一个条目。
答案 0 :(得分：1)
小更新或次要升级的定义包括您需要指定REINSTALL和REINSTALLMODE的事实 - 这只是如何应用它们的定义，因为正如您所说，已经安装了产品代码而您无法重新安装它，只用命令行更新来更新它。
您可以将MSI打包到一个压缩的exe文件中，该exe文件提取MSI并使用相应的命令行运行它，您可能需要编写一个小程序来运行MSI，具体取决于自解压exe工具是否允许您运行外部程序命令。我能想到的唯一另一件事是你使用ProductVersion的其中一个字段来表明这不是客户产品（例如minor = 254），这使你可以自由地使用高达65535的内部版本号，哪一点做了重大升级。在实践中可能需要很长时间。
更改ProductCode只是使它成为新产品，是的，因此除非您指定了主要升级，否则它将并排安装。