我经常遇到合并模块的引用与文件系统不同步的问题。在两次构建之间，某些目录的内容会发生变化。一些文件被删除，一些新文件出现。有没有办法自动刷新这些引用，以便合并模块与文件系统同步？

我想要的只是一个命令行工具，它可以将文件从合并模块 (.msm) 提取到磁盘上。换句话说，我想要 MSI 可能的相同“管理安装”功能：

msiexec /a myProduct.msi TARGETDIR="C:\myInstallation" /qn

以上仅适用于msi（据我所知）。因此，为了获得与合并模块相同的效果，我正在尝试 msidb.exe 和 orca.exe orca 的文档说明：

可以从命令行指定许多合并模块选项...

从合并模块中提取文件

Orca 支持三种不同的方法来提取包含在合并模块中的文件。Orca 可以提取单个 CAB 文件，将文件提取到模块树中，并在将文件合并到目标数据库后将文件提取到源图像中......

提取文件

要从合并模块中提取单个文件，请使用

... -x ... 命令行上的选项，其中是新目录树的所需路径。

指定路径用作提取文件的根路径。所有文件都从模块中嵌入的 CAB 文件中提取，并放置在指定的路径中。提取文件的目录布局基于合并模块的目录树。

这听起来像我需要的。但是当我尝试它时，orca 只是打开了一个编辑器（带有我指定的 msm 的信息），然后什么也不做。我尝试了各种命令行，通常是这样开始的：

orca -x theDirectory theModule.msm

我使用“theDirectory”作为我想要的任何空文件夹。就像我说的 - 它没有做任何事情。

然后我尝试了 msidb，我做了几次尝试，如下所示：

msidb -d theModule.msm -w {存储}

msidb -d theModule.msm -x MergeModule.CABinet

在第一种情况下，我不知道要为 {storage} 放什么。在第二种情况下，事实证明文字字符串“MergeModule.CABinet”是必需的（它是保留名称）。但是，提取的文件柜不保留文件层次结构或“正常”文件名；所以我不能将它用于我的目的。

有人可以解释我在命令行选项上做错了什么吗？有没有其他工具可以做到这一点？

我有一个使用 Visual Studio 部署项目部署的 Windows .net 解决方案。我的 exe 是一个在 x86 或 x64 窗口上运行良好的 win32 应用程序。

但是，我包含了一个来自第三方供应商的合并模块 (*.msm)，它在 x86 和 x64 版本中可用。

现在我可以复制我的整个部署项目并只更改 msm，但我是一个懒惰的人，最好的办法是将两个 msm 都包含在我的安装程序中，并且只安装适合客户端计算机处理器的模块。

有没有办法用可视化部署项目做到这一点？
合并模块似乎缺少像包含的 exe / dll 文件那样的 Condition 属性。

我需要将一些 Crystal Reports XI .dll（craxdrt.dll、crviewer.dll）部署到客户端计算机。Craxdrt.dll 有很多依赖项。我发现最简单的方法是使用提供的合并模块。一直依赖 ClikOnce 部署，我完全不知道如何做到这一点。

如果重要的话：.exe 是用 VB6 编写的，但我有 Visual Studio 2010 来制作安装项目。

谢谢！

我有一些 .msm 合并模块（如果您必须知道的话，适用于 Crystal Reports），我想将它们转换为单个 .msi 安装程序包。我可以使用 Visual Studio 安装项目来做到这一点，但是我无法避免在包中包含 .Net 的要求。

• Visual Studio (2008/2010) 中是否有解决方法？
• 是否有任何免费的第三方实用程序可以执行此任务？

假设我有一个将文件“MyFile.txt”安装到某个位置的合并模块，并且我希望使用该合并模块，但是我想提供与随附的“MyFile.txt”不同的副本合并模块。

是否有可能做到这一点？（对于奖励积分，我如何使用 Wix 做到这一点）

更新：粗略地说MyFile.txt，是我们提供给其他人的可安装项目的打包组件的一部分，然后他们将这些组件与他们自己的组件结合起来以生成安装程序。

在理想的世界中，他们只需要在输出中添加新文件，但是这是对现有系统的替代，他们目前能够在最终安装程序中修改甚至替换项目（如MyFile.txt），因此无需能够对合并模块执行相同的操作，迁移路径将很困难。

如果有更好的解决方案，打包的组件不需要是合并模块，但是合并模块似乎是明智的选择，并且在所有其他方面都提供了一个非常好的可重用安装程序逻辑包。

我可以包含一个 MSM 文件并在 Inno-Setup 中执行它吗？如果没有，我将如何正确安装合并模块？我需要在我的应用程序中安装 SOAP3 并且需要一些指导。我是否必须将 MSM 包装到自定义 MSI 中，然后让 Inno 执行 MSI 文件？我会用什么来为 MSM 创建一个干净而愚蠢的 MSI 文件？感谢您提前提供任何帮助。

我有一个在 InstallShield 2010 中从头开始编写的 InstallScript 项目。它包含三个本机 InstallShield 对象和四个包装 MSM 文件的 InstallShield Merge Module Holder Objects。

当我最初测试该项目时，它在干净的环境中安装良好，但是当我尝试升级到较新版本时，四个合并模块持有者对象中的每一个都产生了“错误 1706。找不到产品 XXXX 的有效来源”消息.

我在网上做了一些挖掘，发现这是一个 Windows Installer 错误，它的发生是因为即使在原始安装介质消失后，MSI 文件也必须存在于机器上。确保这一点的推荐方法是在 Merge Module Holder Object 属性对话框中勾选“本地缓存 msi 包”复选框。

我为所有四个合并模块勾选了该框并重新测试，但这并没有解决问题。然后我查看了这些合并模块实际放置在硬盘上的位置。属性对话框说<DISK1TARGET>，它在运行时解析为C:\Program Files\InstallShield Installation Information\{Product GUID}。查看测试机器，似乎所有四个合并模块都在写入同一个位置，从而覆盖彼此的 MSI 文件。

为了解决这个问题，我编辑了每个合并模块以将其自身缓存到一个唯一的路径<DISK1TARGET>\{Name}。我再次编译和测试，我可以看到每个合并模块现在确实将自己保存到一个唯一的子文件夹中。但是，当我升级时，所有四个错误 1706 消息仍然出现。

有没有人有任何想法？我确定我遗漏了一些明显的东西，但它似乎没有在任何地方记录。:-)

更新：

根据 InstallShield 论坛上的大量帖子，InstallShield 似乎在每次构建 InstallScript 项目时都会为每个嵌入式 MSI 生成一个全新的产品 G​​UID。在更新过程中，InstallShield 引擎会用较新的版本覆盖缓存在目标计算机上的每个 MSI 文件，但在执行它们时，Windows Installer 会说“嘿，这是一个新产品，旧产品的 MSI 在哪里，所以我可以卸载它吗？”，因此出现错误。

是否可以告诉 InstallShield 在每次构建时不要为每个嵌入式 MSI 重新生成产品 GUID？当然，这种行为是对将合并模块嵌入到 InstallScript 项目中的整个想法的嘲弄？:-(

什么是合并模块以及它们是如何使用的？我听说它们是 .msm 文件，但我以前从未见过（我只见过 .msi）。

创建 msi 文件时是否使用它们？它们是否与商业软件一起分发（可能与 msi 文件一起分发？）

他们有什么意义？他们是否要隐藏需要与开发软件一起安装（并因此一起分发）的常见第三方或 Microsoft 组件的安装程序的实现？

谢谢！

我有一个 WiX 项目，其中包括安装用于 x86 的 Visual C++ 2008 运行时组件和一个单独的合并模块。

不幸的是，MSI v4.5 的 .msm 存在一个众所周知的问题。更具体地说，.msm 自定义操作SxSUninstallCA需要 20 分钟才能完成卸载。

所以，长话短说，我决定从新版本的产品中删除 .msm，静默安装带有 .exe 文件的 VC++ 组件。

如果我只更改这个东西（当然还有 ProductCode），安装程序不会检测到机器上已经安装的产品并执行正常安装，而无需先卸载旧版本。

知道这里发生了什么吗？MSI 是否应该检查 UpgradeCode 和 ProductCode 以检测产品是否是系统上已安装的另一个产品的升级？