我们的合作伙伴/经销商之一是设备制造商，他们拥有我们应用程序的特定安装程序，该安装程序还为其硬件安装实用程序和驱动程序。到目前为止，我们已将驱动程序/实用程序放入InstallShield的“支持文件”部分，如果用户输入了特定于我们应用程序的合作伙伴版本的序列号，则通过installscript以静默方式启动实用程序安装程序。合作伙伴最近对我们的许可协议感到担忧，特别是我们不允许将他们的实用程序分发给不是他们客户的用户，只是将他们的安装程序包含在我们的安装程序中（即使我们不运行它）构成分发。有没有办法确保合作伙伴实用程序的支持文件仅包含在我们的应用程序发布中？
我认为仔细控制源文件的路径变量就可以了。您可能无法删除其文件的所有痕迹，但是通过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套件项目的另一种不同风格的编译。
设置风格：通过使用Installshield的Release Flag功能，您可以相对轻松地从同一源项目编译不同风格的设置。这与上面的Suite项目不同，因为这是一个以不同风格提供的单个MSI，而不是按顺序运行的多个MSI文件。它允许您使用标记标记设置的某些部分，以便包含或排除您正在构建的设置。例如，某些功能可以用专业版PRO标记。 Please search the help file for information on release flags。
链接：
如果我的内存服务，你不能使用标志来控制ISSetupFile表。但你能做的是：
1）使用Automation Interface在构建时将这些文件注入ISM。
2）创建具有ISSetupFile表中的资源的合并模块，并将合并模块关联到不同的功能。在功能级别使用释放标志来控制合并哪些合并模块，从而控制ISSetupFile表的内容。