我试图发现捆绑多个可能使用不同安装软件（InstallShield，MS安装程序Service，Wise等）的应用程序并以某种方式自动安装它们的可靠方法。 我还没有看到任何可靠的产品。 这是我想要做的事情：
安装可能使用不同安装程序的多个应用程序。
安装应用程序，而不需要每个应用程序的手动交互。 我希望在主安装程序中有一个选项来定制选项，您可以select所需的应用程序，只需单击“安装”并安装这些应用程序（但不会popup安装这些应用程序）
只有在Windows的“添加/删除程序”菜单中才会显示主安装程序，以便在删除该应用程序时，所有安装的应用程序也将被删除。
控制每个捆绑应用程序的安装参数，以便它们可以安装在逻辑相关的目录结构中。 例如，将所有应用程序安装在Program Files \ Bundled App Set文件夹中。
从我所研究的内容来看，实际上只有几种方法：
外部安装，这将简单地启动每个应用程序的安装程序，并需要每个安装程序的手动交互（但几乎打破了上述所有目标，但至less会安装在交互后select的所有应用程序）
假设每个安装程序都通过应答文件或传递给安装程序的标志来支持无人值守/无提示安装。
重新安装使用可以跟踪安装过程中对系统的更改的软件进行安装，并logging这些更改，然后重新打包为新的安装程序。 我读过这不是很可靠，往往经常打破。 它可能会检测到问题，如添加到Windows的服务。
还有一个使用合并模块的第四个选项，但这只有在每个应用程序使用相同的MS安装程序服务时才有效。 我没有因此而列出。
这是真正意义上的问题，关于这个最好的方法。 一些软件，我可以访问和可以重新包装，其他软件我不。 我宁愿不要使用混合系统，比如使用＃1和＃2，但是如果必须，我必须使用。
我想可能有这样做的权利，我愿意接受任何意见或build议，以达到这样的效果 – 希望最终不会令人难以置信的脆弱。 也许这是不可能的？ 任何帮助表示赞赏。 谢谢。
多年来，我一直沿用pjhayward的解决scheme。 我们公司使用了数百个不同的计划，其中一些来自大型商业提供商，另一些来自一人一方的业务。 这些供应商的技术熟练程度都在地图上，特别是在devise安装人员时。
我认为供应商交付的MSI是黄金标准（尽pipe在包装devise上仍然有很多变化）。 我相信，使用微软免费的Orca工具（embedded到一个或多个平台SDK中），创build转换文件以将这些软件包强制转换为典型的布局非常简单。 我们根据function类别自定义“开始菜单”以对程序进行分组，我们更改安装目录以按照供应商在“程序文件”文件夹内对应用程序进行分组，并且我们完全放弃了桌面快捷方式。 如果适用，可能会应用序列号和许可证服务器地址，也许会禁用自动更新服务等。
使用MSI的最大好处是，Microsoft的组策略（通过Active Directory工作并包含在所有Windows Server许可证中）可以将这些软件包及其转换自动地或通过用户请求部署到指定的机器组。 我们使用自动方法，为所有机器分配通用应用程序，向可能使用这些应用程序的人分配CAD应用程序，向特定机器分配Adobe应用程序（愚蠢的每席授权）等等。有效执行此操作的细节将是一个单独的SF问题如果还没有问及回答。
对于许多非MSI格式的安装程序，我们会经历类似于pjhayward的重新打包过程。 这样做最显着的缺点是重新打包的安装失去了原始安装程序内置的任何智能。 对平台差异（比如说32或64位系统）的敏感度会被破坏，可能需要额外的重新包装来覆盖每个平台。 不pipe目标机器的初始状态如何，都将根据样机来决定是否安装和/或更新第三方组件。 等等。
说到第三方组件：我们尽一切努力通过单独的软件包来安装每个组件，而不pipe厂商是否经常愿意将所有的东西捆绑在一起。 他们的策略对于一个人在他/她自己的机器上手动安装一些软件产品是有意义的，但是在多节点，多产品自动化安装的情况下会失败。 无论有多less供应商依赖于MSXML 6或一些模糊的许可证pipe理工具，我们通常都安装一次，通常在安装分发的产品之前。 这也可以帮助我们减less意外的版本降级，因为我们可以很容易地判断捆绑的版本比我们已经部署的版本更老还是更新。
我们使用Attachmate的WINinstall，它是以Windows Server 2003光盘的forms发布的。 我们有完整的产品许可证，但LE版本，与Orca结合，偶尔embeddedvbscript补充，已经足够满足我的需求。 Evan Anderson对WINinstall的评论是有效的，但是我们已经能够忍受它的疣了。
pjhayward的列表（当前）掩盖了一个关键的步骤：清除捕获的安装包，然后使用它来在别处执行安装。 不需要的文件和registry项通常是捕获过程的一部分，在对后续安装造成损害之前，识别并删除它们非常重要。 查找顺序状态registry项可能完全错误的机器已经运行了一段时间，索引服务或Windows更新caching文件创build中捕获的东西。
请注意，许可证不在我的答案范围内，但与这种情况非常相关。 散装分销技术必须与每个产品的许可协议授予的实际使用权的意识平衡。
我希望这有帮助。 这可能比您所要求的要多，这与您的问题所描述的部署方法并不完全匹配，但是这是我们多年以来可行的解决scheme。
当你在处理那些没有安装代码的软件时，确实没有一个“正确答案”。
如果您使用第三方软件进行此操作，您可能需要考虑许可协议。 服务器故障不是律师，但如果这是你要在你的组织外分发的东西，我会让你的律师检查出来。
“重新包装”对不同的人意味着不同的事物。 在我看来，这意味着要为别人的应用程序build立一个新的安装程序。 通常这些是MSI软件包，但它可以很容易地是一些其他的设置系统。 这可以通过自动化工具，“手工”或这些策略的组合来完成。
使用自动化工具重新打包可以创build出色的安装，或无可救药的破坏。 盲目地使用重新包装工具，而不仔细检查它创build的包可能会导致一个巨大的混乱。 一些工具（Wininstall LE，我在看你）默认创build真正丑陋的MSI文件（每个组件一个文件，一切都是keypath）。
通过对原始安装程序的作者的“意图”进行反向工程重新包装，可以使重新包装的安装变得更简洁，但是你必须深入了解并确定原始安装程序是否具有你没有看到的行为你的testing机器。 这最终是一个逆向工程（可能是挫折）的练习。
如果你能通过运行无人值守的设置来获得必要的应用程序，我想你会得到最干净的configuration。 如果你担心添加/删除程序（ARP）列表，那么我想你可以让你的安装程序“shell”在每个第三方设置完成后修改ARPregistry项来删除它的条目。 （就我个人而言，我会离开ARP条目…）
如果这个产品是用于COTS的，那么我会特别小心，检测你正在安装的第三方程序的现有安装，并进行适当的处理。 我记得曾经用来处理这个糟糕的老式教育软件，会盲目地捣毁QuickTime的安装版本，并用一些难看的Win16版本代替它，无论我喜不喜欢。 啊…
如果你在组织外部和其他系统pipe理员（比如说我）有这个潜力需要处理这个事情，请考虑我们的利益。 我们希望能够悄然安装您的产品，并希望能够维护您安装的第三方组件。
要实现所有目标，唯一真正可行的select是选项＃3。
重新打包的主要原因通常是不可靠的，当应用程序最初安装时，它们都被安装到同一个系统，而不先卸载其他应用程序。 这意味着你最终会得到一个序列依赖关系，以确保你安装了所有正确的共享库。
如果应用程序A安装了myLib.dll版本1.0.0.1，并且应用程序B使用相同的版本，则更改检测系统将不会识别出应用程序B需要myLib.dll，除非它在程序文件夹中保留一个副本。 对于使用Microsoft的可再发行组件库的应用程序而言，这尤其成问题，因为这些应用程序可能会或可能不会在目标机器上启动。 大多数使用自定义库的应用程序往往会将它们保留在程序文件夹中。
要让选项＃3工作，即使远程可靠，这是我会做的：
创build一个虚拟机来安装各种应用程序。 我熟悉的大多数虚拟机软件都可以让您设置虚拟驱动器，以便您决定是否提交对虚拟驱动器映像的更改。 启动并运行后，打开上述function。
启动更改检测软件。
安装一个应用程序/更新/其他，确保你安装到Program Files \ BundledAppsWhatever
删除将放置在添加/删除控制面板中的应用程序的registry项
完成变更检测过程。
将重新打包的应用程序移动到您的物理机器上。
重置VM撤消磁盘，所以你有一个干净的系统。
根据需要重复步骤2-7。
现在，尽pipe如此，我还不是重新打包解决scheme的最新产品，所以我不知道有什么能够给您提供您想要的添加和删除程序的灵活性。
如果你的公司足够大（即他们的IT预算是“巨大的”），有几种产品可以沿着这些方向发展。
如果您正在寻找适合中小型环境的东西，那么您将会查找安装标志，然后以某种方式编写脚本。
也许你应该尝试Npackd（ http://code.google.com/p/windows-package-manager/ ）