Hello,
My app have several OEM, previously I created separated install project per OEM. Now I'm trying to do all in one project with help of Product and release configuration. Currently I have problem with major upgrade items. Different OEM's should support different major upgrade (different upgrade version etc), but I cant' find release or product flags in major upgrade. Does anybody knows what can be done in such case ?
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Different major upgrades with Product configuratio
Started by
Nikkartman
, Aug 14 2010 14:39
2 replies to this topic
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 14 August 2010 - 23:57
I have done this, and believe it or not I used the same upgrade code for all setups. The upgrade code is used to define a family of related setups, hence I kept it the same for all flavors. This allows each OEM setup to realize that there is a related product on the machine, regardless of its flavor - all just using a single GUID.
I decided that all higher versions of setups would uninstall all previous installations before installing itself. This was done via a major upgrade. In accordance with good major upgrade practice I also added protection against downgrading (install a lower version over a higher version). If you need to add more logic, you can always do so using a custom action. For example to warn against overwriting another OEM version. Remember to ensure not to display any messages if your setup runs in silent mode.
I also used a single project to compile all OEM versions. Anything else or you are in source control hell for real. I kept the version numbers the same across all regular and OEM versions of the setups - you have to in order to stay sane and have a chance to deal with the accumulation of flavors of your setup.
There are many pitfalls here, particularly if you chose to use different setup version numbers for different OEM versions. This is a terrible design that generally indicates a faulty design.
I decided that all higher versions of setups would uninstall all previous installations before installing itself. This was done via a major upgrade. In accordance with good major upgrade practice I also added protection against downgrading (install a lower version over a higher version). If you need to add more logic, you can always do so using a custom action. For example to warn against overwriting another OEM version. Remember to ensure not to display any messages if your setup runs in silent mode.
I also used a single project to compile all OEM versions. Anything else or you are in source control hell for real. I kept the version numbers the same across all regular and OEM versions of the setups - you have to in order to stay sane and have a chance to deal with the accumulation of flavors of your setup.
There are many pitfalls here, particularly if you chose to use different setup version numbers for different OEM versions. This is a terrible design that generally indicates a faulty design.
Regards
-Stein Åsmul
-Stein Åsmul
Zweitze
-
- Full Members
- 522 posts
Posted 17 August 2010 - 11:12
Like Glytzhkof states you really need to think about all possibilities, upgrade schemes etc.
In my case, once I had a project with significant different releases. But it also had some DLLs EXEs etc. that were the same.
Given the structure of the software, only one release could be installed on the computer. (By the structure I mean: all releases were using the same Registry keys, using the same file extensions etc., and you can't have them fight with each other)
In my situation every release had its own upgrade code. Setup also installed a marking registry key somewhere, containing -among other stuff- the upgrade code. Setup checked at the start whether that key existed and contained a different upgrade code, in which case the user was warned and Setup aborted.
The moral of this story: really think how you want to deal with computers that install software from different OEMs, how to deal with different versions, cross upgrades etc.etc. Chances are that the standard InstallShield wizards have no support for your demands, so learn about the inner workings of Major Upgrades and the MajorUpgrade table.
Getting back to the original question, the release wizard had no suitable flags, so I wrote a VBS script that modified the MSI afterwards.
In my case, once I had a project with significant different releases. But it also had some DLLs EXEs etc. that were the same.
Given the structure of the software, only one release could be installed on the computer. (By the structure I mean: all releases were using the same Registry keys, using the same file extensions etc., and you can't have them fight with each other)
In my situation every release had its own upgrade code. Setup also installed a marking registry key somewhere, containing -among other stuff- the upgrade code. Setup checked at the start whether that key existed and contained a different upgrade code, in which case the user was warned and Setup aborted.
The moral of this story: really think how you want to deal with computers that install software from different OEMs, how to deal with different versions, cross upgrades etc.etc. Chances are that the standard InstallShield wizards have no support for your demands, so learn about the inner workings of Major Upgrades and the MajorUpgrade table.
Getting back to the original question, the release wizard had no suitable flags, so I wrote a VBS script that modified the MSI afterwards.