I've accepted that this is a limitation of Windows Installer, and made separate components per instance for the things that don't uninstall correctly, as per hidenori's comment in the thread he linked to. ... View more

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 ... View more

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. ... View more

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! ... View more

I'm also in the exact same situation as the original poster and would really like to know what the best practice for dealing with this is. I can't imagine that it's an uncommon scenario; some way of dynamically linking support files seems like an obvious and useful feature that InstallShield doesn't seem to have an answer for. So what do other people do to get around this? ... View more