This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- I'd go with a Suite
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 17, 2013
03:17 AM
Design for Modular Installer
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.
Regards,
Srikant Lakhanpal
+91-9313802001
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.
Regards,
Srikant Lakhanpal
+91-9313802001
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 01, 2013
01:13 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 09, 2013
02:30 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 10, 2013
06:37 PM
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.
-Sandra
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.
-Sandra
![](/skins/images/8C9D13A71C7F7695F3262372C0172D68/responsive_peak/images/icon_anonymous_message.png)