我正在尝试找到一种可靠的方法来捆绑可能使用不同安装程序软件（InstallShield、MS 安装程序服务、Wise 等）的多个应用程序，并以某种方式自动安装它们。我还没有看到任何产品可以可靠地做到这一点。以下是我希望它做的事情：
安装可能使用不同安装程序的多个应用程序。
安装应用程序时无需手动交互每个应用程序。我更希望主安装程序中有一个自定义选项，您可以在其中选择所需的应用程序，只需单击“安装”即可安装这些应用程序（但不会弹出这些应用程序的安装）
让主安装程序仅显示在 Windows 中的“添加/删除程序”菜单中，这样当删除该应用程序时，所有已安装的应用程序也会被删除。
控制每个捆绑应用程序的安装参数，以便它们可以安装在逻辑相关的目录结构中。例如，将所有应用程序安装在 Program Files\Bundled App Set 文件夹中。
根据我的研究，实际上只有几种方法可以做到这一点：
外部安装，只需启动每个应用程序的安装程序，并要求每个安装程序进行手动交互（但这几乎破坏了上述所有目标，但至少会在交互后安装选择的所有应用程序）
无人值守/静默安装假设每个安装程序通过应答文件或传递给安装程序的标志支持它。
使用可以跟踪安装过程中系统变化的软件重新打包安装，并记录这些变化，然后将其重新打包到新的安装程序中。我读到过这种方法不太可靠，而且经常出问题。它在检测添加到 Windows 的服务等内容时可能会出现问题。
还有第四种选择，即使用合并模块，但这只有在每个应用程序都使用相同的 MS 安装程序服务时才有效。因此我没有列出它。
这实际上是一个关于最佳解决方法的意见问题。有些软件我可以访问并重新打包，而其他软件则不能。我宁愿不采用混合系统，例如使用 #1 和 #2，但如果必须这样做，那我就不得不这样做。
我认为有某种方法可以正确完成这项工作，我愿意听取任何意见或建议，以使这样的事情能够正常进行——希望最终不会变得非常脆弱。也许这是不可能的？任何帮助我都感激不尽。谢谢。
答案1
多年来，我一直使用与 pjhayward 的解决方案类似的技术。我们公司使用数百种不同的程序，其中一些来自大型商业供应商，另一些来自个人兼职。这些供应商的技术水平参差不齐，尤其是在设计安装程序方面。
我认为供应商提供的 MSI 是黄金标准（尽管软件包设计仍存在很大差异）。使用 Microsoft 的免费 Orca 工具（我相信嵌入在一个或多个平台 SDK 中），可以相当轻松地创建转换文件以将这些软件包强制转换为我们的典型布局。我们自定义“开始”菜单以按功能类别对程序进行分组，我们将安装目录更改为按供应商在 Program Files 文件夹中对应用程序进行分组，并且我们完全取消桌面快捷方式。如果合适，将应用序列号和许可证服务器地址，也许会禁用自动更新服务等。
使用 MSI 的最大好处是 Microsoft 的组策略（通过 Active Directory 工作，包含在所有 Windows Server 许可证中）可以自动或根据用户请求将这些包及其转换部署到指定的计算机组。我们使用自动方法，将通用应用程序分配给所有计算机，将 CAD 应用程序分配给可能使用它们的用户，将 Adobe 应用程序分配给特定计算机（愚蠢的按座位许可）等。如果尚未提出和回答，那么有效执行此操作的详细信息将是一个单独的 SF 问题。
对于许多非 MSI 格式的安装程序，我们会进行与 pjhayward 类似的重新打包过程。这样做的最大缺点是重新打包的安装程序会丢失原始安装程序中内置的任何智能。对平台差异（例如 32 位或 64 位系统）的敏感性将受到破坏，可能需要额外的重新打包才能覆盖每个平台。关于安装和/或更新第三方组件的决定将基于示例机器，而不管目标机器的初始状态如何。等等。
说到第三方组件：我们尽一切努力通过单独的软件包安装每个组件，而不管供应商经常希望将所有组件捆绑在一起。他们的策略对于在自己的机器上手动安装少量软件产品的人来说是合理的，但在多节点、多产品自动安装的情况下却行不通。无论有多少供应商依赖 MSXML 6 或一些晦涩难懂的许可证管理工具，我们都会安装它们一次，通常是在安装它们随附的产品之前。这也有助于我们最大限度地减少无意的版本降级，因为我们可以轻松判断捆绑版本是否比我们已经部署的版本更旧或更新。
我们使用 Attachmate 的 WINinstall，它以精简版的形式随 Windows Server 2003 CD 一起分发。我们拥有完整产品的许可证，但精简版与 Orca 和偶尔嵌入的 vbscript 补充相结合，已经足以满足我的需求。Evan Anderson 对 WINinstall 的评论是正确的，但我们能够忍受它的缺点。
pjhayward 的列表（目前）忽略了一个关键步骤：在使用捕获的安装包在其他地方执行安装之前，先清理它。捕获过程中通常会拾取不需要的文件和注册表项，因此，在它们对后续安装造成损害之前，识别并删除它们非常重要。查找诸如连续状态注册表项之类的内容，这些内容对于运行了一段时间的机器来说可能完全错误，以及在捕获过程中创建的索引服务或 Windows 更新缓存文件。
请注意，许可不在我的回答范围内，但与此类场景非常相关。批量分发技术必须与对每个产品许可协议授予的实际使用权的认识相平衡。
希望对您有所帮助。这可能比您要求的更多，并且与您的问题描述的部署方法并不完美匹配，但这是我们多年来发现的可行的解决方案。
答案2
当您处理没有安装代码的软件时，实际上并没有“正确答案”。
如果您使用第三方软件进行此操作，则可能需要考虑许可协议。Server Fault 不是律师，但如果这是您要在组织外分发的东西，我建议您的律师检查一下。
“重新打包”对不同的人来说有不同的含义。在我看来，这意味着为其他人的应用程序构建一个新的安装程序。通常这些是 MSI 包，但它也可以是其他安装系统。这可以使用自动化工具、“手动”或这些策略的某种组合来完成。
使用自动化工具重新打包可能会创建完美无缺的安装，也可能创建完全损坏的安装。盲目使用重新打包工具而不仔细检查其创建的软件包可能会导致巨大的混乱。某些工具（Wininstall LE，我正在研究你）默认会创建非常非常丑陋的 MSI 文件（每个组件一个文件，所有内容都是一个键路径）。
通过逆向工程“手工”重新打包原始安装程序作者的“意图”，可以使重新打包的安装更加干净，但您必须深入研究并弄清楚原始安装程序是否有您在测试机器上看不到的行为。这最终会成为逆向工程的练习（并且可能会令人沮丧）。
如果您可以通过运行无人值守安装程序来安装必要的应用程序，我认为您将获得最干净的配置。如果您担心添加/删除程序 (ARP) 列表，那么我想您可以让安装程序“shell”在每个第三方安装程序完成后修改 ARP 注册表项以删除其条目。（就我个人而言，我会保留 ARP 条目......）
如果此产品是用于 COTS 用途，我会格外小心，检测您正在安装的第三方程序的现有安装并进行适当处理。我记得我曾经处理过一些糟糕的旧教育软件，它会盲目地丢弃已安装的任何版本的 QuickTime，并用一些丑陋的 Win16 版本替换它，无论我是否喜欢它。呃……
如果您将此软件分发到组织之外，而其他系统管理员（比如我）可能需要处理此问题，请考虑我们的利益。我们希望能够默默安装您的产品，并且我们希望能够维护您安装的第三方组件。
答案3
实现所有目标的唯一真正可行的选择是选项#3。
重新打包通常不可靠的主要原因是，当应用程序最初安装时，它们都会安装到同一个系统上，而不会先卸载其他应用程序。这意味着您最终会得到一个序列依赖关系，以确保安装了所有正确的共享库。
如果应用程序 A 安装了 myLib.dll 版本 1.0.0.1，而应用程序 B 使用相同的版本，则变更检测系统根本无法识别应用程序 B 需要 myLib.dll，除非它在程序文件夹中保留一份副本。这对于使用 Microsoft 的可再发行库的应用程序尤其成问题，这些库可能在目标计算机上，也可能不在目标计算机上。大多数使用自定义库的应用程序倾向于将它们保存在程序文件夹中。
为了使选项 3 能够可靠地工作，我会这样做：
创建虚拟机来安装各种应用程序。我熟悉的大多数 VM 软件都允许您设置虚拟驱动器，以便您可以决定是否将更改提交到虚拟驱动器映像。启动并运行后，打开上述功能。
启动变化检测软件。
安装一个应用程序/更新/其他，确保将其安装到 Program Files\BundledAppsWhatever
删除将上述应用程序放置在添加/删除控制面板中的注册表项
完成变化检测过程。
将重新打包的应用程序移至您的物理机器。
重置 VM 撤消磁盘，这样您就拥有一个干净的系统。
根据需要重复步骤 2-7。
现在，尽管如此，我并不了解目前提供的重新打包解决方案，所以我不知道有任何解决方案可以按照您描述的方式为您提供添加和删除程序所需的灵活性。
答案4
也许你应该尝试 Npackd (http://code.google.com/p/windows-package-manager/）