Multi Install Madness

I got back to work after a week long vacation. There was apparently a high priority problem with the rollout of our latest software. This was a major upgrade. However the uses expected to run the new and old versions of our software side by side on the same machine. Ummm I said I thought we did not support that. Apparently we we supposed to.

The problem was that every time you install our software, we uninstall any old copy that is already on the system. Normally that is the expected behavior. However the customer wants a specific version of the old software to stick around. The lead on my team decided that we wanted a multi-install capability turned on in our Installshield project.

Multi install sounded like a bad idea to me. Sure enough, the lead was having all kinds of trouble with it. In fact, he now had two problems. The customer's old versions were getting uninstalled. And he could not figure out how to get multi install to work in all scenarios.

So I backed the guy up. I told him the InstallShield and Windows theory is that a product knows what kind of product it is. And it we got it set up to remove all prior copies of itself. If you do not want to remove prior copies, you need to create a new product. For InstallShield, I had a hunch that this was some sort of unique string or number like a GUID that uniquely identified our product.

As soon as I led my team leader down that path, he found a Product GUID setting in InstallShield. With the click of a button, he was able to generate a new GUID and solve the customer problem. He backed out his multi install problem. The moral of the story is to first have a deep understanding of the problem. Then you can clearly see what it takes to resolve it.