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
- :
- Re: Major Upgrades for multiple instances
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
‎Jun 08, 2010
09:01 AM
Major Upgrades for multiple instances
Multiple instances are critical to my installation, but support for it appears to be very lacking in InstallShield 2010. I need to be able to do major upgrades, but there doesn't seem to be any acceptable way to use them with multiple instances. The only workaround I could find was in this one-and-a-half year old thread for InstallShield 2009. Has there really not been any progress on this since then?
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2010
10:30 AM
What problems are you encountering? Do each of your instances have their own UpgradeCode, and is the option "Products sharing my Upgrade Code" selected on your major upgrade item?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 08, 2010
10:44 AM
Yes to both. The problem is that the instance selection dialog uses the product code instead of the upgrade code to detect installed instances, so by changing the product code for a major upgrade it doesn't present the installed instances for selection. So only the first instance can every be upgraded unless end users pass the instance id to setup.exe, and asking them to do that isn't really a viable option.
Thank you for responding so quickly!
Thank you for responding so quickly!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 09, 2010
10:36 AM
We've got a work order tracking this enhancement request now: IOC-000076675. I don't have any timeframe for when this might be implemented.
Just to make sure we're on the same page, while I think installing, e.g., Instance 3 in the major upgrade will already effectively major upgrade Instance 3 of the previous version if it's on the machine, you currently can't reasonably select to upgrade Instance 5 without installing the upgraded instances 1-4 first. Ideally the enhanced selection dialog would look for related earlier versions, and let you select to upgrade ones that are present even if it means skipping an instance.
Just to make sure we're on the same page, while I think installing, e.g., Instance 3 in the major upgrade will already effectively major upgrade Instance 3 of the previous version if it's on the machine, you currently can't reasonably select to upgrade Instance 5 without installing the upgraded instances 1-4 first. Ideally the enhanced selection dialog would look for related earlier versions, and let you select to upgrade ones that are present even if it means skipping an instance.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 09, 2010
12:49 PM
MichaelU wrote:
We've got a work order tracking this enhancement request now: IOC-000076675. I don't have any timeframe for when this might be implemented.
That's what I figured (the thread I linked to mentioned work order #IOC-000077274). Multi-instance support is the reason I recommended using InstallShield, so this is a bit disappointing.
Just to make sure we're on the same page, while I think installing, e.g., Instance 3 in the major upgrade will already effectively major upgrade Instance 3 of the previous version if it's on the machine, you currently can't reasonably select to upgrade Instance 5 without installing the upgraded instances 1-4 first. Ideally the enhanced selection dialog would look for related earlier versions, and let you select to upgrade ones that are present even if it means skipping an instance.
You can't upgrade any instance other than 0 unless you explicitly pass in the instance id to setup.exe because the selection dialog uses the product code to identify related earlier versions (instead of the upgrade code like it probably should), and the product code has to change between major upgrades.
Now, the whole reason I wanted to use major upgrades was because RemoveExistingProducts let's me remove obsolete files without explicitly enumerating them in RemoveFile (which is a huge asset - possibly even a necessity - when using dynamic file linking). If there was some way to get it to work in a minor upgrade I'd be okay, but I haven't had any success so far.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 10, 2010
11:27 AM
You certainly cannot easily select which instance to upgrade, but I'm pretty sure that as you install each next instance of the major upgrade version, each successive instance of the previous version will be upgraded (removed) if it is present. If that's true, the capability is present but confusing as it looks like you're explicitly selecting to install an arbitrary new instance for each major ugprade.
Thanks for calling my attention back to the other tracking number. They appeared to be the exact same request so I have merged them in our system.
Thanks for calling my attention back to the other tracking number. They appeared to be the exact same request so I have merged them in our system.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 10, 2010
01:16 PM
Hm, you're right, I hadn't noticed it was doing that. Not quite sure what kind of installation that behavior is intended for though; I'd imagine my situation of needing multiple independent environments (e.g. testing, training, production, etc.) to be more common.
So I guess my best option is write some kind of replacement for setup.exe; luckily I don't need any of the other functionality it provides. It's a shame we don't have any way of customizing the one InstallShield creates.
Anyway, I appreciate the help MichaelU.
EDIT: The instance transforms get embedded in the MSI, right? I expected to be able to do something like: msiexec /i install.msi TRANSFORMS=:InstanceId1.mst, but that doesn't do it. Is there some way to list the names of all transforms embedded in an MSI?
EDIT 2: Nevermind; I don't know what I was doing wrong but I can accomplish what I wanted to now. For anyone that needs to determine what transforms are embedded in an MSI, you can query the temporary table "_Storages", which will not show up in Orca/InstallShield. You can use some VBScript:
So I guess my best option is write some kind of replacement for setup.exe; luckily I don't need any of the other functionality it provides. It's a shame we don't have any way of customizing the one InstallShield creates.
Anyway, I appreciate the help MichaelU.
EDIT: The instance transforms get embedded in the MSI, right? I expected to be able to do something like: msiexec /i install.msi TRANSFORMS=:InstanceId1.mst, but that doesn't do it. Is there some way to list the names of all transforms embedded in an MSI?
EDIT 2: Nevermind; I don't know what I was doing wrong but I can accomplish what I wanted to now. For anyone that needs to determine what transforms are embedded in an MSI, you can query the temporary table "_Storages", which will not show up in Orca/InstallShield. You can use some VBScript:
Dim installer
Set installer = Wscript.CreateObject("WindowsInstaller.Installer")
Dim base, view, record
Set base = installer.OpenDatabase(Wscript.Arguments(0), 0)
Set view = base.OpenView("SELECT Name FROM _Storages")
view.Execute()
Do
Set record = view.Fetch
If record Is Nothing Then Exit Do
Wscript.Echo record.StringData(1)
Loop
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 05, 2011
12:44 PM
Sorry to bump this, but I have exactly the same problem in Installshield 2011 and I'm *extremely* frustrated by it. If I instance several instances of version 1 of our software, then try to upgrade to version 2, it doesn't detect the previous versions properly because the product code has changed, so to the user it looks like a new install which is exactly what I didn't want.
I chose Installshield because of its multiple instance support, so now we've deployed our first release only to discover that upgrading multiple instances does not work after all. I'm seriously not impressed.
Is there a solution to this problem? At the very least there should be a workaround or a patch so that installshield behaves as it claims to.
Right now I'm regretting the fact that I didn't do our first release with InnoSetup or something similar so that I wouldn't be in this mess, but alas because there's now an msi entry on hundreds of client machines it's too late to change architecture.
I chose Installshield because of its multiple instance support, so now we've deployed our first release only to discover that upgrading multiple instances does not work after all. I'm seriously not impressed.
Is there a solution to this problem? At the very least there should be a workaround or a patch so that installshield behaves as it claims to.
Right now I'm regretting the fact that I didn't do our first release with InnoSetup or something similar so that I wouldn't be in this mess, but alas because there's now an msi entry on hundreds of client machines it's too late to change architecture.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 06, 2011
02:05 PM
That sort of UI experience is our standard, whether you have single or multiple instances. If you want to provide a different experience for the major upgrade scenario, you will need to modify your dialogs. Perhaps create a MajorUpgradeWelcome dialog which is shown only if your major upgrade's action property or properties are set. Or perhaps modify InstallWelcome's control events to go down a different branch.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)