我没有修补/升级安装的经验。
我们有一个带有标准（wix创建的）msi的wix bundle设置，其中以这种方式添加到bundle中：
<MsiPackage SourceFile="MySetup.msi" Id="MySetupId" Cache="yes" DisplayInternalUI="no" SuppressSignatureVerification ="yes" Visible="no" >
所以在“添加/删除软件”部分中显示的是捆绑包，而不是msi本身。
msi和bundle都签名了。
目前我们发布的版本是＆＃34; 2.1.0.BuildNumber＆＃34;。
bundle.wxs有升级代码A. msi有产品代码B和升级代码C.
不幸的是，这个版本包含一个平均错误但我们不想发布＆＃34; v2.2.0.BuildNumber＆＃34;只是因为这个bug，但是＆＃34; 2.1.1.BuildNumber＆＃34;，所以我们需要一个补丁。
这里最好的做法是什么？我们应该只创建一个像这里描述的msp文件
http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html？
这会打破捆绑包和msi之间的关系吗？此补丁是否会显示在“添加/删除程序”部分？
或者是否有可能将该捆绑包用于补丁？
目标是，我们的客户可以在不卸载旧版本的情况下安装补丁，但可以使用以前发布的捆绑包卸载整个范围。
答案 0 :(得分：0)
我的个人建议是，除非绝对必要，否则不要创建补丁。你避免了很多麻烦。 IMO的主要问题是补丁不适合源控制和CI。首先，您无法自动增加内部版本号并将其包含在版本号中 - 它必须保持不变。其次，创建msp补丁需要在新构建期间存在来自先前构建的二进制文件。在MS技术中，之前的msi应该存在，在你引用的WiX技术中，你将需要来自前一版本的* .wixpdb。第三个（或第一个？），补丁是一次性操作，CI不能自动执行。
如果捆绑包未将其包包含到exe中但下载它们，则新捆绑包版本只能下载更改的包，因此安装时间会很短。否则你运气不好。
您需要为错误的msi创建一个msp升级。升级可能会也可能不会更改msi版本，但如果确实如此，则msi的版本将与捆绑包的版本不匹配。用户无论如何都看不到msi版本。
您可以直接安装msp。卸载软件包时，也会卸载msp。我不知道在ARP中是否可以看到msp（msi不可见）。
您可以创建一个补丁包。这是一个独立的捆绑包，有自己的升级代码。它将包含
<Bundle .... ParentName="Name of your main bundle"...>
<RelatedBundle Id="YourMainBundleUpgradeCode" Action="Patch" />
将MspPackage与您的msp一起包含在Chain中。
此捆绑包将作为“主捆绑包的名称”的子项在“已安装的更新”中显示，并且将与主捆绑包一起卸载，或者在安装新版本的主捆绑包时。
当未安装此特定版本的主捆绑包时，您还需要包含一个条件以防止安装修补程序包。没有文档化的API来检测包（尽管您可以使用RegistrySearch），但您可以为主包中包含的msi的特定版本执行ProductSearch。
请注意，具有相同版本号的主版本的新版本将并行安装（ARP中将有两个相同的条目），具有更高版本号的新版本将自动卸载以前的版本。因此，您无法新发布主要包。