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
- :
- Suggestions On Building Installation Package
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
‎Aug 03, 2013
09:41 AM
Suggestions On Building Installation Package
I am looking for some input regarding the building of an installation package for our application. Here are the specifics:
Even though we might replace a large number of files, this is still considered a minor upgrade for us, as our Product Revision might simply change from 9.00.0123 to 9.00.0124.
So, is this something that is doable? If so, how would people recommend I structure the project?
I'm especially interested in how you manage this upgrading logic, when releases will be coming out as fast as every two weeks. For example, do I have to save every IS build and point back to those, or just the original build?
Thanks in advance!
Steve
1. Want a full installer (for initial installations) plus have it simultaneously perform upgrades for users who have already performed the initial installation.
2. We will release new, minor versions of our software at least once every two weeks.
3. On one type of minor upgrade, it possible that only 5% of the original files need to be replaced, the remaining 95% can stay as is.
4. On another type of minor upgrade, it's possible that up to 90% of the original files will need to be replaced, but the remaining 10% are critical files and cannot be replaced.
5. I don't really want to have the original installation removed, rather just have the installer replace the changed files.
2. We will release new, minor versions of our software at least once every two weeks.
3. On one type of minor upgrade, it possible that only 5% of the original files need to be replaced, the remaining 95% can stay as is.
4. On another type of minor upgrade, it's possible that up to 90% of the original files will need to be replaced, but the remaining 10% are critical files and cannot be replaced.
5. I don't really want to have the original installation removed, rather just have the installer replace the changed files.
Even though we might replace a large number of files, this is still considered a minor upgrade for us, as our Product Revision might simply change from 9.00.0123 to 9.00.0124.
So, is this something that is doable? If so, how would people recommend I structure the project?
I'm especially interested in how you manage this upgrading logic, when releases will be coming out as fast as every two weeks. For example, do I have to save every IS build and point back to those, or just the original build?
Thanks in advance!
Steve
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 05, 2013
08:30 AM
This topic comes up a lot, so here are some guidelines. The summary is that it's possible to do what you describe with Windows Installer minor upgrades, but you may prefer to use major upgrades.
As for structuring things, definitely run through all the sample upgrade scenarios you can think of - upgrading existing files, adding new files, removing old ones - as this can influence your structure or even your choice of minor or major upgrades (it's hard to safely remove a file in a minor upgrade, however the GAC and WinSxS don't always cooperate with major upgrades). If you don't have time to plan and test minor upgrade and patch scenarios now, you probably won't have time to ensure they work later.
Typically, unless you have strong reasons to favor a patch, I would recommend avoiding the complexity; further I tend to recommend major upgrades instead of minor upgrades, as they are easier to reason about and fix.
- The version change of your product does not influence whether you must do a minor or a major upgrade; whether you change the .msi Product Code is what determines this.
- Some changes require major upgrades (such as changing the feature tree; see "Major Upgrade vs. Minor Upgrade vs. Small Update" in the help).
- Minor upgrades can be delivered as patches or as full packages (technically so can major upgrades, but it's not worth it); patches require a previous package to be installed (see "Packaging Options for Upgrades" in the help).
- If you are releasing a stream of minor upgrades, you will want each to reference the last released build; if you are releasing a stream of patches, you will need to reference all supported released versions (i.e, if you can patch from A, B, or C to D, D will need to reference A, B and C in your patch build).
- If you are releasing as a major upgrade, you have somewhat more flexibility in your package, as Windows Installer is less likely to require 100% compliance with component rules. (But you should still follow them.)
- Minor upgrades, especially delivered as patches, require more planning and testing than major upgrades, as the interaction is more complicated.
As for structuring things, definitely run through all the sample upgrade scenarios you can think of - upgrading existing files, adding new files, removing old ones - as this can influence your structure or even your choice of minor or major upgrades (it's hard to safely remove a file in a minor upgrade, however the GAC and WinSxS don't always cooperate with major upgrades). If you don't have time to plan and test minor upgrade and patch scenarios now, you probably won't have time to ensure they work later.
Typically, unless you have strong reasons to favor a patch, I would recommend avoiding the complexity; further I tend to recommend major upgrades instead of minor upgrades, as they are easier to reason about and fix.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2013
09:10 AM
Michael,
Thank you for the detailed response.
After much testing, I really was unable to make the Minor Upgrade work correctly. It seemed much more logical to treat every release as a Major Upgrade, and simply change the Product Code each time.
I've designed my critical files (database files) as a separate component and set the component at "Permanent". This way, when the Major Upgrade removes the prior version, my critical files remain untouched. Then it can install the new version and all should be correct.
I don't know if this is technically the correct way, but it seems to work fine.
Thanks again!
Steve
Thank you for the detailed response.
After much testing, I really was unable to make the Minor Upgrade work correctly. It seemed much more logical to treat every release as a Major Upgrade, and simply change the Product Code each time.
I've designed my critical files (database files) as a separate component and set the component at "Permanent". This way, when the Major Upgrade removes the prior version, my critical files remain untouched. Then it can install the new version and all should be correct.
I don't know if this is technically the correct way, but it seems to work fine.
Thanks again!
Steve
