Major Upgrades for multiple instances

[ajk7c1]

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?

[MichaelU]

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?

[ajk7c1]

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!

[MichaelU]

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.

[ajk7c1]

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.

[MichaelU]

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.

[ajk7c1]

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:

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

[yottskry]

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.

[MichaelU]

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.