One of our partners/resellers is a device manufacturer who has a specific installer of our application that also installs utilities and drivers for their hardware. Up until now we had put the driver/utility into the "Support Files" section of InstallShield and launched the utility installer silently via installscript if the user entered a serial number that was specific to this partners edition of our application. The partner recently came to us with concerns about their licensing agreement, specifically we are not allowed to distribute their utility to users who are not their customers and simply including their installer with our installer (even if we don't run it) constitutes distribution. Is there any way to make sure that the support files for the partners utility is included only with their release of our application?
I think carefully controlling your source files' path variables will do the trick. You may not be able to remove all traces of their files, but by overriding where the path variable points at the release level, you can at least use an alternate set of empty files (with the same names) for all the other build configurations. Such empty files means you aren't distributing their code. So unless even the file names themselves are a problem, give this a try.
(You didn't mention what version of InstallShield you're running, but I found equivalent documentation back through InstallShield 2014, the earliest I could find online. I think it's been around longer than that.)
Driver Installation: For the record, driver installation is apparently changing. See this answer. Essentially drivers are to be distributed via
Windows Update, or at least via astandalone packagewithout the need for an installer.
- Windows Hardware Dev Center dashboard is now available for "hardware tasks":
Hardware certificationCollaborative driver developmentDriver distribution through Windows UpdateI thought I'd just mention it. I know little about it to be honest.
OEM?: As to your actual question, I am not sure I understand the requirements properly. You need a special setup for these guys only? Sort of like an OEM-version of your own setup?
Support Files: I do not know of a built-in way to have release-specific support files. Maybe you can use the COM-automation feature to automate the process of updating the ISM with the correct configuration for every build, but I wouldn't go for such a clunky approach. There seems to be objects for it: ISWiSetupFile and ISWiSetupFiles. I have never tried them. Here is a COM Automation Sample from way back.
Suite Project: I might just bundle their installer with your own and then wrap it all in an Installshield Suite project. These are essentially bootstrapper projects that launch MSI, MSP, EXE and other executables to run in sequence. I am not sure what editions of Installshield has those projects available. This means that their own setup runs before or after your setup - not from within your own setup, but in sequence as invoked by the suite's setup.exe - and you could deliver your own setup without the third party drivers and tools inside it. That would just be another compile of a different flavor of the Installshield suite project.
Setup Flavors: You can relatively easily compile different flavors of setups from the same source project by using Installshield's Release Flag feature. This is different from the above Suite projects since this is a single MSI that is delivered in different flavors, not several MSI files run in sequence. It allows you to tag parts of your setup with flags for inclusion or exclusion from the setup you are building. For example some features could be tagged with PRO for professional version. Please search the help file for information on release flags.
Links:
I think carefully controlling your source files' path variables will do the trick. You may not be able to remove all traces of their files, but by overriding where the path variable points at the release level, you can at least use an alternate set of empty files (with the same names) for all the other build configurations. Such empty files means you aren't distributing their code. So unless even the file names themselves are a problem, give this a try.
(You didn't mention what version of InstallShield you're running, but I found equivalent documentation back through InstallShield 2014, the earliest I could find online. I think it's been around longer than that.)
If my memory serves, you can't use flags to control the ISSetupFile table. But what you can do is:
1) Use the Automation Interface to inject these files into your ISM at build time.
2) Create merge modules that have the resources in the ISSetupFile table and associate the merge modules to different features. Use release flags at the feature level to control which merge modules get merged and therefore what the contents of the ISSetupFile table is.
© 2022 - 2024 — McMap. All rights reserved.