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
- :
- Single .msi, Two .msi's, or A Transform - How to Best Deploy Two Product Configs?
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
‎Jul 13, 2016
04:05 PM
Single .msi, Two .msi's, or A Transform - How to Best Deploy Two Product Configs?
Hi all,
Here's my latest situation. We have a set of various installs, some much more complex than others, some wrapped in an .exe etc. What we may soon have to do is offer the same applications, only rebranded (new icon's, different product name, shortcuts with description verbiage changes, etc). Here are my thoughts...
1) Duplicate all package templates, make the required changes to the second set of installations, and maintain two streams of installs for basically the same app. This is probably the least desirable as, like I said some of the installs are complex with many DuplicateFiles table entries, the maintenance of which is time consuming for the current installation, among other things.
2) Change our installs to maybe add another Feature to house the changes for the additional branding tasks. The only problem with this is on first install, I would have to offer a control for configuration 1 or configuration 2 selection. This just would present the opportunity for users to make a mistake. I can see a way around this if the second configuration is based on or can be tied to some other universal registry entry that could be searched, property set.
3) Create and use a Transform to deliver the package changes. I'm thinking this is the way to go.
Again, as far as I know, here is what is required for the rebranding...
New Product Name
Same Shortcuts, but with verbiage that reflects the alternate name
New graphics/icons - I'm thinking most of these can be embedded in the actual .exe so nothing may need to be done here.
As far as the installation graphics themselves, I'm thinking that we move to a more universal, company centered set of graphics for the installs so they are not product specific.
Does anyone have any pointers, experience delivering different configurations of the same app.
Any help appreciated!!
Here's my latest situation. We have a set of various installs, some much more complex than others, some wrapped in an .exe etc. What we may soon have to do is offer the same applications, only rebranded (new icon's, different product name, shortcuts with description verbiage changes, etc). Here are my thoughts...
1) Duplicate all package templates, make the required changes to the second set of installations, and maintain two streams of installs for basically the same app. This is probably the least desirable as, like I said some of the installs are complex with many DuplicateFiles table entries, the maintenance of which is time consuming for the current installation, among other things.
2) Change our installs to maybe add another Feature to house the changes for the additional branding tasks. The only problem with this is on first install, I would have to offer a control for configuration 1 or configuration 2 selection. This just would present the opportunity for users to make a mistake. I can see a way around this if the second configuration is based on or can be tied to some other universal registry entry that could be searched, property set.
3) Create and use a Transform to deliver the package changes. I'm thinking this is the way to go.
Again, as far as I know, here is what is required for the rebranding...
New Product Name
Same Shortcuts, but with verbiage that reflects the alternate name
New graphics/icons - I'm thinking most of these can be embedded in the actual .exe so nothing may need to be done here.
As far as the installation graphics themselves, I'm thinking that we move to a more universal, company centered set of graphics for the installs so they are not product specific.
Does anyone have any pointers, experience delivering different configurations of the same app.
Any help appreciated!!
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2016
05:29 PM
I'm not as experienced as many here, but I had to do something somewhat similar with an install for a printer that they wanted repackaged in three slightly different forms (it was for the different models of printers which essentially use mostly the same hardware).
What I did was use release flags and custom custom actions that checked the release flag and set the product name thusly (I didn't know any better). But I think there is an easier way if you setup multiple releases and on the General tab just give each a different product name, upgrade code (if you want them to be treated separate) and specify release flags.
I did find that using release flags was a very easy way to specify which features to include, as each release did have some different files unique to it. It worked out pretty OK in the end but your mileage may vary.
What I did was use release flags and custom custom actions that checked the release flag and set the product name thusly (I didn't know any better). But I think there is an easier way if you setup multiple releases and on the General tab just give each a different product name, upgrade code (if you want them to be treated separate) and specify release flags.
I did find that using release flags was a very easy way to specify which features to include, as each release did have some different files unique to it. It worked out pretty OK in the end but your mileage may vary.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 13, 2016
06:15 PM
Jamesbo wrote:
I'm not as experienced as many here, but I had to do something somewhat similar with an install for a printer that they wanted repackaged in three slightly different forms (it was for the different models of printers which essentially use mostly the same hardware).
What I did was use release flags and custom custom actions that checked the release flag and set the product name thusly (I didn't know any better). But I think there is an easier way if you setup multiple releases and on the General tab just give each a different product name, upgrade code (if you want them to be treated separate) and specify release flags.
I did find that using release flags was a very easy way to specify which features to include, as each release did have some different files unique to it. It worked out pretty OK in the end but your mileage may vary.
Ah, NICE! I didn't even think of that and I've also used Release Flags in the past! That just might work here as well.
