Background : We have requirement to develop Modular Installer in Install Shield. Earlier version of our product installer was developed in Install Jammer. Tool Used : Install Shield 2012 Spring / License : Professional Edition
Design Requirement : Req_1. Divide the one big product into multiple independent modules, so that each modules can be updated independently in subsequent versions of product. So that no need to send one Complete Big Installer package to client. Req_2. We have planned that multiple developers will code/develop this installer. So, we will need a way to merge the parts developed by the set of developer. [*Note : We have professional license only]
Design Proposal:confused: : Req_1 : Develop independent MSI for each modules of our Big Product. And one master MSI which will contain all independent MSI [developed against each independent module] as a Nested MSI concept. Req_2 : Covert project file format as XML [default type is binary], so that merging could be possible. Although merging is not so easy in this format also.
Question for IS Developers, Trainers & Gurus : Is this correct way to achieve above requirements? Or, we are not using this tool in its optimized way? Please give your valuable suggestions.
The answer I would typically push for your design involves InstallShield Premier (because of Suite/Advanced UI projects), which would allow you to better handle multiple MSI projects in a single installation.
The term "nested" references a deprecated/obsolete option in Windows Installer that is severely out of favor and you should avoid. If you are considering that route, which has to be managed a lot like a single MSI, you'd be better served breaking apart your design within the MSI through the use of InstallShield Collaboration (DIM files) or Merge Modules.
The key decision here is whether you want to break up your project at the package level (multiple MSI files consumed into a single suite) or feature level (multiple DIM or MSM files consumed into a single MSI), and whether you have or can upgrade to the editions of InstallShield that support that pattern.
I would recommend creating merge modules (MSMs) wherein you logically group your files. This grouping can be done based on features or other relationship within the files and then create a msi which consumes the merge modules.
Also design separate merge modules for 32-bit and 64-bit binaries. Do not mix 32-bit and 64-bit binaries in a single merge module. You could design a merge module which contains platform neutral file then create two different merge modules for 32-bit and 64-bit binaries.
going with the Merge Module approach seems to speak against the first requirement, that the user should be able to update modules independently in subsequent installs.
So going from that requirement, I'd go with MichaelUs first suggestions to upgrade to Premier and go with a Suite project that includes multiple MSI's. In subsequent Releases one can either upgrade the full Suite or only send out the individual MSI packages that changed.
