4 replies to this topic

[cmose]

hello,
I've run this question around the installshield forums and installshield.com and have yet to find anything. I have an installscript MSI project in devstudio 9 and I can't seem to find where to make my install a multi-instance install (the documentation says that there should be a Maintenance Experience property under project properties but I have no such property available to me). I'm wonderin if it is even possible to create or "hack" a multi instance install using this kind of installshield project and if so how would one go about it? Many thanks to anyone who can lend a hand here!
thanks

[KathyMorey]

I'm pretty sure that multi-instance install only applies to InstallScript projects, not InstallScript MSI or pure MSI - it's the MSI portion that doesn't work with multiple installations on the same machine.

Kathy

[cmose]

hmmnnn I was afraid of that but I'm trying to figure out a way around it - my understanding of the reason it doesn't work is that at build time the guid/install id is set equal to the product id and that information is stored so that when another install run using the same product id it pulls up the modify/etc., but I'm hoping someone can help me thing of a way to get around this (somehow generate a new installid that is passed through the target properties of setup.exe or something like that?) - maybe create an xml file and a "loader" for setup.exe, store the xml file in system or windows dir. or temp or something, store a mess of install id's in the xml file and have the loader select a new one from the file everytime it is run (remove used ones from the file as they are used)....any suggestions?

thanks much

[Glytzhkof]

Any documentation you have seen on this subject might have been for MSI 3 which is now in beta. I believe there is some sort of multiple instance transform coming, but I am frankly not sure how this is supposed to work.

The core issue with multiple instances of windows installer setup is that in principle each installation should have completely new component GUID's for all files. The reason is that the path and file name is the primary key for each component (or the path in general, could be a registry key), and the component GUID is the unique "counter" or reference code if you like. I am not sure how the new transform concept will work, maybe it transforms all component code based on the new product's GUID or similar.

It has been a long time since I tried this, but I was under the impression that if you change the product code, the system would see the new setup as an unrelated setup unless you tie them together using the upgrade table. As such you should be able to install major upgrades multiple times. Indeed a common problem with major upgrades is that there are multiple instances of the product in add/remove programs.

Avoid this duplication if you can, at all cost. It is messy.

[cmose]

glytz,
thanks much I had read a little about the multi instance transforms. My problem actually deals with running the same setup again (e.g., after choosing one setuptype I want to be able to rerun that same setup again as if it was new).