小编Aar*_*ton的帖子

我在单核Windows 7机器上运行电子应用程序.似乎每当我使用fs库执行几乎任何文件I/O时,CPU对电子过程的峰值达到~100%,执行文件I/O可能需要一分钟.

一个特别慢的函数是fs.readFileAsync().我正在阅读的文件很小,但似乎需要很长时间才能完成.

我还在Windows 7上使用双核,Windows 8.1,Windows 10和Ubuntu 15.10运行这个确切的代码,并且这些操作系统都没有遇到这个问题,它似乎只是单核的Windows 7机器.(所以我几乎肯定是编写的代码没有问题).

有谁知道为什么会发生这种情况？有没有解决这个问题的方法？核心数量会影响电子应用的性能,这似乎很奇怪.同样,这只是Windows 7,因此单核Windows 8.1或Windows 10计算机不会出现此行为.

我只想在升级和修补程序上运行 Wix 自定义操作，而不是安装/重新安装或修复。因此，基本上只有当应用程序的版本号增加时，才应该运行此自定义操作。我尝试了以下规则，它在修补时完全禁用了自定义操作：

<Custom Action="upgrade_action"
        Before="InstallFinalize">Installed AND NOT REMOVE AND UPGRADINGPRODUCTCODE</Custom>

我可以做什么来实现这个目标？

我有一个 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 文件重新安装并继续从那里修补？