Installation 使用捆绑或msi修补安装？

我没有修补/升级安装的经验

我们有一个wix捆绑包设置，其中包含一个标准（wix创建的）msi，通过以下方式添加到捆绑包中：

<MsiPackage SourceFile="MySetup.msi" Id="MySetupId" Cache="yes" DisplayInternalUI="no" SuppressSignatureVerification ="yes" Visible="no" >

因此，在添加/删除软件部分显示的是捆绑包，而不是msi本身

msi和捆绑包都已签名

目前我们发布的版本是“2.1.0.BuildNumber”

bundle.wxs具有升级代码A msi的产品代码为B，升级代码为C

不幸的是，这个版本包含一个平均错误，但我们不想仅仅因为这个错误而发布“v2.2.0.BuildNumber”，而是“2.1.1.BuildNumber”，所以我们需要一个补丁

这里最好的做法是什么？我们是否应该创建一个如下所述的msp文件

?

这会破坏捆绑包和msi之间的关系吗？此修补程序是否会显示在“添加/删除程序”部分

或者是否有可能将捆绑包用于补丁

---

我们的目标是，我们的客户只需安装修补程序而无需卸载旧版本，但可以使用以前发布的捆绑包卸载整个范围。

我个人的建议是，除非绝对必要，否则不要创建修补程序。你避免了很多麻烦。IMO的主要问题是，补丁不适合源代码管理和CI。首先，您无法自动增加内部版本号并将其包含在版本号中-它必须保持不变。第二，创建msp修补程序需要在新的构建过程中出现以前构建的二进制文件。在MS技术中，以前的msi应该存在，在您引用的WiX技术中，您将需要以前构建中的*.wixpdb。第三个（或第一个？），补丁是一次性操作，不应该由CI自动连续执行

如果捆绑包不将其软件包包含到exe中，而是下载它们，那么新的捆绑包版本只能下载更改过的软件包，这样安装时间就会很短。否则你就倒霉了

您需要为有bug的msi创建msp升级。升级可能会更改msi版本，也可能不会更改，但如果更改，则msi版本将与捆绑包的版本不匹配。用户无论如何都看不到msi版本

您可以直接安装msp。卸载捆绑包时，msp也将被卸载。我不知道msp是否在ARP中可见（msi不可见）

您可以创建补丁包。这是一个独立的包，有自己的升级代码。它将包含

<Bundle .... ParentName="Name of your main bundle"...>
    <RelatedBundle Id="YourMainBundleUpgradeCode" Action="Patch" />

将msp包装与msp一起包含到链中

此捆绑包将作为“主捆绑包名称”的子项显示在已安装的更新中，并将与主捆绑包一起卸载，或在安装新版本的主捆绑包时卸载

当未安装此特定版本的主捆绑包时，您还需要包括一个防止安装修补程序捆绑包的条件。没有记录在案的API来检测捆绑包（尽管您可以使用RegistrySearch），但您可以对主捆绑包中包含的msi的特定版本执行ProductSearch

---

请注意，具有相同版本号的主捆绑包的新版本将并行安装（ARP中将有两个相同的条目），具有更大版本号的新版本将自动卸载以前的版本。因此，您无法发布主包的新版本。

您创建补丁而不是常规包的动机是什么？在旧时代的CD/DVD和慢速互联网的动机是，补丁只包含变化，比主包小得多。这仍然是您产品的一个问题吗？另一个动机是软件包版本保持不变。但您建议更改它：main package 2.2.0，new package 2.2.1是一个新的软件包版本，可以作为软件包的新版本而不是补丁安装。最后，如果用户可以从ARP或使用最新版本卸载当前安装的版本，则“可以使用以前发布的捆绑包卸载”有些人为，当前安装的安装包。我们的安装包含几个类似行李的html文件和一些保持不变的拉链。这就是为什么我们只想部署修改过的二进制文件，基本上是一些DLL。版本号的增加不是强制性的，但目前我们的产品版本与二进制文件的构建版本相同。我想我不明白你的最后一点。在ARP中，现在只有捆绑包，而不是真正安装的msi可见。因此，当应用补丁后，删除整个文件的唯一方法仍然是使用捆绑包的ARP条目或bundle.exe。不幸的是，我们在捆绑包的c#代码中做了一些错误的事情。直接应用MSP效果很好，但ARP中的捆绑包版本不再正确。我们的捆绑包中有一些代码，当PackageState.Superseded时会中止安装，因此我无法使用我们的捆绑包卸载应用程序。我试试你的第二个建议。补丁包的升级代码不能与主包相同，对吗@dvom：“请注意，具有相同版本号的主捆绑包的新版本”表示补丁捆绑包的相同版本号？这是我们要阻止的。你还有另一个反对修补的理由。传统的安装程序智慧认为，1.0安装程序只有在准备并测试1.1之后才能准备就绪。在您的情况下，准备并测试了一个修补程序：（如果burn engine先卸载修补程序包，修补程序包可能会工作。希望是这样，我只是不知道。另外，请确保您的msp修补程序是可卸载的（查看文档）。如果唯一的更改是新的dll版本，则应该可以。当从APR卸载修补程序包时，它首先删除msp，然后删除主包，因此至少单击一次即可。尝试卸载主包时，它仍然显示由于被取代而导致的错误