How do I Install Multiple Versions of MyProgram (same PC, VS2008)?

Question

I have a big MDI Suite application that I've written for our company. It is installed on two Citrix servers, and is then accessed by hundreds of Windows terminals across the plant.

Before installing updates, I (the sole developer) test my new routines until I am satisfied that it is going to perform how I expect it to. This generally works, but it has the group manager worried.

He wants me to install a BETA version that can be tested on in our workplace environment by others.

To do this, I would need to install my application twice on the Citrix servers machines so our employees can test it (right?); however, when I try to install the application again on the same PC (i.e. the Citrix server), Windows says it is already installed.

The VS2008 Setup and Deployment Installer has a Product Code. Should I just change this? What problems do I need to be aware of? Do I need to keep track of two Product Codes (one for testing, and one for release)?

How do I install 2 working versions of the same application on 1 PC?

Answer 1

Since you want to allow dual installs that should work. I'd make a new "beta" installer that may target a different install directory to keep bleed over to a minimum.

Here's the MSDN write up on changing Product Code for some more info.

Another possible angle, that may be a lot simpler.....is there a test/staging Citrix server you can host it on? That's how we roll out changes here. But that ultimately depends on your Citrix environment/servers in farm...

Oh, and in relation to tracking the product code, in my experience(right or wrong), that isn't as important as making sure you keep your UpgradeCode is sync.

Answer 2

The safest way is to create new ProductCode, new UpgradeCode, new TARGETDIR and make sure there are NO shared directories (besides the system dirs). Make Windows Installer think it's a completely different product.

Changing the ProductCode, but NOT the UpgradeCode may cause existing components to upgrade. When the install runs the FindRelatedProducts action, it will locate anything with the matching upgrade code and attempt to upgrade matching components.

I strongly agree with cutrisk - stage the whole thing somewhere else first (install released version, upgrade to BETA, open it for internal testing, etc.) Then carefully roll it out to customers.

Trust me, you do NOT want your installer to bring down someone elses production service(s) because your BETA "upgrades" some component and the whole system falls over.

Answer 3

I'd give the beta .exe a different name: app_beta.exe. You can use the same setup to deploy it. You can also keep changing your upgradeCode with each version of the beta or prod release- it's ok for them to overlap.

prod: 2.0

beta: 2.1

beta: 2.2

prod update: 2.3

next beta: 2.4

Answer 4

InstallShield 2009 and later support "multiple instances":

e.g.: http://blog.deploymentengineering.com/2008/03/installshield-2009-beta-part-i.html