我们的合作伙伴/经销商之一是设备制造商，他拥有我们应用程序的特定安装程序，该安装程序还为其硬件安装实用程序和驱动程序。到目前为止，我们已将驱动程序/实用程序放入 InstallShield 的“支持文件”部分，并在用户输入特定于我们应用程序的此合作伙伴版本的序列号时通过 installscript 静默启动实用程序安装程序。合作伙伴最近来找我们，担心他们的许可协议，特别是我们不允许将他们的实用程序分发给不是他们的客户的用户，并且简单地将他们的安装程序包含在我们的安装程序中（即使我们不运行它）构成分发。 有什么方法可以确保合作伙伴实用程序的支持文件仅包含在他们发布的我们的应用程序中？
【问题讨论】：
标签： installshield
我认为仔细控制源文件的路径变量可以解决问题。您可能无法删除其文件的所有痕迹，但通过overriding where the path variable points at the release level，您至少可以为所有其他构建配置使用一组备用的空文件（具有相同的名称）。这样的空文件意味着您没有分发他们的代码。因此，除非文件名本身有问题，否则请尝试一下。
（您没有提及您运行的是哪个版本的 InstallShield，但我通过 InstallShield 2014 找到了等效文档，这是我在网上找到的最早的文档。我认为它的存在时间比这更长。）
【讨论】：
驱动程序安装：据记录，驱动程序安装显然正在改变。 See this answer。本质上，驱动程序是 通过
Windows Update或至少通过standalone package分发 无需安装程序。
- Windows Hardware Dev Center dashboard 现在可用于“硬件任务”：
Hardware certificationCollaborative driver developmentDriver distribution through Windows Update我想我只是提一下。老实说，我对此知之甚少。
OEM？：至于您的实际问题，我不确定我是否正确理解要求。您只需要为这些家伙进行特殊设置吗？有点像您自己设置的 OEM 版本？
支持文件：我不知道拥有特定版本支持文件的内置方式。也许您可以使用 COM 自动化功能来自动化更新 ISM 的过程，并为每个构建使用正确的配置，但我不会采用这种笨拙的方法。它似乎有对象：ISWiSetupFile 和 ISWiSetupFiles。我从未尝试过它们。 Here is a COM Automation Sample 从回来的路上。
套件项目：我可能只是将他们的安装程序与您自己的安装程序捆绑在一起，然后将其全部包装在 Installshield Suite project 中。这些本质上是启动 MSI、MSP、EXE 和其他可执行文件以按顺序运行的引导程序项目。我不确定哪些版本的 Installshield 有这些项目可用。这意味着他们自己的设置在您的设置之前或之后运行 - 不是从您自己的设置中运行，而是按照套件的 setup.exe 调用的顺序运行 - 您可以在没有第三方的情况下交付自己的设置里面的驱动程序和工具。这只是对不同风格的 Installshield 套件项目的另一个编译。
Setup Flavors：您可以使用 Installshield 的 Release Flag 功能相对轻松地从同一源项目编译不同风格的设置。这与上述套件项目不同，因为这是以不同风格交付的单个 MSI，而不是按顺序运行的多个 MSI 文件。它允许您使用标记来标记设置的一部分，以便从您正在构建的设置中包含或排除。例如，某些功能可以用 PRO 标记为专业版。 Please search the help file for information on release flags.
链接：
【讨论】：
如果我没记错的话，您不能使用标志来控制 ISSetupFile 表。但你可以做的是：
1) 在构建时使用自动化接口将这些文件注入您的 ISM。
2) 创建具有 ISSetupFile 表中资源的合并模块，并将合并模块与不同的功能相关联。在功能级别使用发布标志来控制合并哪些合并模块，从而控制 ISSetupFile 表的内容。
【讨论】：