问题标签 [msi-patch]

我需要使用带有 Installshield 2012 的 Patch Design 创建的一系列可卸载补丁。前两个补丁在卸载时工作正常。然而，第三个补丁，当且仅当在补丁 1 和/或补丁 2 已经应用时卸载，会产生错误：

其中有 26 个关于不同文件的错误。文件或组件没有明显的模式，或者没有特征

注意：如果我只应用了补丁 3，卸载不会产生此错误..

我在补丁设计中使用相同的选项创建了所有三个补丁。我理解的唯一明显区别是补丁 3 包含比前两个更多的更改（文件更新）。让我重复一遍：更多的变化。

我的问题是：

1. 为什么只有在安装了一系列补丁的情况下才会发生这种情况，而不仅仅是第三个补丁本身？

2. 为了防止补丁卸载尝试从构建补丁时仅用于设计时的位置获取文件，我必须做些什么？或者也许这是设计使然，但是缓存太重或太混乱了..？

更新 - 更多信息（由 Glytzhkof 请求）：该补丁包含 96 个文件更改，大约是基本 MSI 软件包大小的一半。它实际上与“开发”分支工作无关。添加了几个新文件。有些最初被删除（当我发现我们真的在做补丁时不得不把它们放回去......）。如果我再描述这种情况，可能会冒犯您作为该领域的专业人士。

我一直在尝试销售主要升级，只需对安装程序进行一些调整即可使其不再需要补丁。我们产品的卸载需要参数才能使其成为非交互式（我们需要此参数才能在主要升级方案中工作，它目前只是卸载序列的一部分）。这是唯一真正的问题——但解决它会付出很多。但是，决定不解决该问题。我尝试在每次迭代中“解决”这个问题。没有骰子。有人告诉我，我们需要主要版本的补丁 - 所以在这里我试图让尾巴摇摆不定。

是的，补丁可以更快（让我在这里扮演魔鬼的拥护者）。但真的，30 秒和 90 秒之间的区别，这些东西什么时候自动部署？是的，我还考虑通过调整文件成本来优化安装程序，以查看它是否会使其更快，但即便如此，我相信还有另一个原因会要求提供补丁。

另一个更新：1308 错误中提到的文件不在目标系统的%windir%Installer\$PatchCache$\Managed\{PackedProductCodeOfMyBaseMSI??}

文件夹。这可能会导致 1308，因为如果我从此缓存中删除更多文件，我会得到与丢失文件相对应的相同错误。问题可能是，为什么不是所有文件都在这个PatchCache文件夹中？

我在几个客户站点看到我们的一个补丁出现不寻常的零星故障。最终的错误代码是 1648（无法找到该组补丁的有效序列），这是因为尝试从其中一个补丁转换读取摘要信息流时发生错误 2219（无效的安装程序数据库格式）。但我怀疑这只是早期无声错误的副作用。我们的补丁都使用 MinorUpdateTargetRTM 属性，因此实际上没有什么可排序的，因为任何以前安装的补丁都会自动取代。我们的客户通常使用数百台几乎完全相同的笔记本电脑，并且大多数人都安装了这个更新。在大多数情况下，只有一台设备无法更新。

日志的关键部分如下。初始化已完成，Windows 安装程序服务器进程开始执行执行序列。最后一个正常日志条目是“正在执行操作：ISSetupFilesExtract”。ISSetupFilesExtract 是执行序列中的第一个操作。有三分钟的停顿，然后看起来整个安装以某种方式重置并重新开始。下一个日志条目由客户端进程写入，通常服务器进程将继续运行执行序列。在安装结束之前，我不希望看到来自客户端进程的另一个日志条目。我怀疑这里正在发生某种灾难性故障，但我不知道它可能是什么。只有在发生这种神秘的重置之后，SequencePatches 才会失败。第一次就成功完成了。

我的问题是，有谁知道是什么导致安装过程像这样“重置”，我能做些什么吗？正如我所说，这个补丁在 99% 的时间里正常安装。可获取故障机器的完整日志：https ://docs.google.com/document/d/1LK6HdIcetKOGqFbi5nGKAuDolvhZ3PcLxzJHv2wNDsQ/pub 。谢谢。

回应评论的附加信息：

我们的产品将 MSI 用于服务包版本，将补丁用于点版本。每个补丁都是累积的，并通过 MinorUpdateTargetRTM 属性取代所有以前的补丁。它们主要用于更新应用程序文件。我们始终包含整个文件以提高可靠性，并且不使用位级补丁。基本 MSI 为 46 MB，包含 1778 个文件（这是一个复杂的企业产品）。失败的补丁非常大，57 MB。它添加了 240 个新文件并更新了 413 个现有文件。

我使用 Installshield 为我的产品创建了一个补丁。当我应用补丁时，产品文件会成功更新。但是，当尝试卸载补丁时，它会成功卸载或删除目标 m/c 中新添加到补丁的 dll，但不知何故，由于补丁而被修改的某些 dll 或 exe 在卸载补丁后不会恢复。

当我看到某些 dll 的版本时，日期和时间是应用补丁的日期，并且在卸载补丁后版本仍然是新版本。这意味着 dll 不会恢复。

有人可以帮助理解为什么我的一些 dll 在补丁卸载后没有恢复。我已正确遵循补丁卸载规则。

有一个财务应用程序，它的man执行文件是用Delphi语言编写的。我正在处理它的设置项目。它有很多步骤。最令人困惑的步骤是安装具有自定义条件的 MS SQL Server。所以我只是想知道在我的应用程序设置期间是否可以安装 MS SQL Server 2012（标准版或更高版本）？

我负责创建几个 MSI 和他们的 MSP。我使用 MSI 安装了所有这些，并且我的公司名称显示正确，即在“程序和功能”下。但是，在我使用 MSP 安装他们的更新后，我发现他们在“程序和功能”->“已安装的更新”中的“发布者”列对于某些产品是空白的，而其中一些有我的公司名称。

看到那些空白的发布者后我很惊讶，因为我总是使用以下 Patch.wxs 作为模板并添加 componentRef：

我认为 Patch/@Manufacturer 是发布者专栏的专栏。谁能帮我？

我正在尝试从最新和以前的 MSI 中生成 MSP，如下所示：

• 先前的 MSI 是固定的并用作基线。
• 最新的 MSI 是通过每晚对包含的文件进行的新修改生成的，并且每一代都会获得一个新的 ProductVersion（服务器上的每个构建都会发生这种情况）。
• 机器上安装了作为基线的先前 MSI；假设它的版本为 1.0.0.0。
• 第一次构建时生成的 MSP 安装成功，现在产品版本为 1.0.0.1。
• 最新的 MSI 现在是 1.0.0.2 并且有新的修改，我们想要生成一个新的 MSP 来获得机器的这些修改，MSP 是根据以前的 MSI 1.0.0.0 和最新的 1.0 之间的差异生成的.0.2.

问题是我们在尝试安装第二个 MSP 时遇到错误：

不支持卸载包。

以下是错误日志：

允许这样做吗？或者我们是否必须在每次安装 MSP 时更改以前的 MSI，所以我们只为每个 MSP 保留不同的文件？

我正在尝试使用 wix 创建一个补丁（.msp 文件），其中我将一些文件复制到应用程序的安装路径（程序文件）并尝试添加注册表项。
在安装（使用 msi）时，它按预期工作正常，二进制文件被更新。但是当我尝试应用补丁时它不起作用，这意味着二进制文件没有得到更新。

但是，我观察到，当我再次尝试应用补丁时，二进制文件似乎已更新。
似乎在这里我通过提供 Guuid 添加组件。

问题是：为什么它适用于全新安装而不是使用补丁时？是否可以使用补丁（msp）添加具有新 guuid 的组件？

我试图帮助一位朋友弄清楚是否可以在 Max/MSP javascript 中实现 DSP 算法。他在课堂上被告知，他寻求我的帮助，但我找不到任何方法来处理实际样品。

TL;DR 是否可以使用 javascript 在 Max/MSP 中获取样本并返回它们？谢谢

我正在尝试并行构建一对 WiX 补丁项目（补丁创建项目..），但是我的 64 位配置总是因 PatchWiz 错误而失败：

我试过了：

• 运行前清理临时文件夹。
• 切换配置顺序。
• 在执行之间添加睡眠/超时

没有运气。

这是我正在执行的 build.proj：

我受 PatchWiz 的摆布吗？或者我可能做错了什么？任何黑客的想法？（并且不要说我首先通过修补/MSP 做错了！我意识到这一点！除此之外，我是一个重大升级 MSI 类型的人）。

我有一个 Wix 安装程序，它将程序安装为我已成功制作补丁以实现以下升级的版本：

1.0.0 -> 1.0.1

1.0.0 -> 1.0.2

1.0.1 -> 1.0.2

这很有效，我每次都必须从 1.0.0 到目标内部版本号制作新的 .msp 文件。因此，根据我的理解，补丁在幕后是如何工作的，如果我最初有一个从 1.0.0 到 1.0.1 的补丁，那么如果我要运行的话，我会创建一个从 1.0.0 到 1.0.2 的新补丁新补丁，旧补丁将被卸载，新补丁将替换它。

如果我的理解是正确的，那么这意味着补丁文件的大小会随着您更改代码的次数不断增加，所以我想要一个解决方案来解决这个问题，在某个时候我会增加次要版本，然后重新开始修补过程.

例如，我想这样做：

1.0.0 -> 1.0.12 可以用 patch1.msp 处理。然后我创建了一个 patch2.msp，它将开始创建基于版本 1.0.12 的补丁。示例升级路径可能如下所示：

1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x

有没有办法做到这一点？还是我需要使用 .msi 文件重新安装并继续从那里修补？