InstallAware

The Transform Instance allows multiple instances of the same product to be installed ... but it "loses" any links to the multiple installs. i.e. when you try to install a newer version of one of the instances, the user must manually first find and uninstall the previous instance, then re-run the setup and specifiy all the same settings (program group, folder etc).

I was wondering if, instead, we could just change the PRODUCTCODE in the script at the beginning, perhaps from a command line parm from the user running the setup. Then the user could completely manage multiple instances by using something like:
MySetup.exe /UNIQUE_GUID=Install_1
and
MySetup.exe /UNIQUE_GUID=Install_2

... and then when we release new versions of the product (and a new installer), they simply re-run

MySetup.exe /UNIQUE_GUID=Install_1
and
MySetup.exe /UNIQUE_GUID=Install_2

and the great InstallAware logic will uninstall the correct (the correct instance) previous version, and then install the new version.

I just tried just setting the PRODUCTCODE and TITLE manually at the start of the script (to some "dummy value"), and it ALMOST works. But when it comes time to uninstall the previous version when I run a new setup version, the Install/Remove MSO Package in the NEEDSUPGRADE section fails with, the "parameter is incorrect"

The Add/Remove Programs entry works fine ... but kicking off the uninstall of the previous version from inside the script always fails. There is probably some registry settings in the HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall
that are a little messed up.

Is there a way to accomplish what I am trying to do? Do you know why the Install/Remove MSO Package could fail? Is there a different method to remove the previous version based on a runtime generated PRODUCTCODE?

Thanks!

I haven't experimented with what you've described, however, its easy to tell why (Un)Install MSI Setup would fail - it references the GUID you are changing, therefore the parameter is indeed incorrect (refers to a product not yet installed on the system).

As such, correctly setting the value $PRODUCTCODE$ referenced in the plug-in command would probably achieve the effect you want.

Nice experimentation

The (Un)Install MSI Setup is pointing to the correct (new) GUID. Since it uses $PRODUCTCODE$ as the GUID, it picks up my hard coded change (in my test I am setting PRODUCTCODE to TEST1234 at the top of the script). I even hard-coded this GUID in the "Use Package Guid" field.
It looks like somewhere the installer may still be using the original PRODUCTCODE GUID from the setup, even though I am manually changing it on the first line.
Would you expect just setting PRODUCTCODE to TEST1234 at the first line of script to "work"?
Thanks!

Any thoughts?

I am just trying to understand things better ... I just created a new project using the "Basic Setup" template (no changes). I DO NOT CHANGE the ProductCode ... just left the default generated {EAEA0AD1-8470-4DC6-8D10-D7C152316C24}

I run the install.

Shouldn't I be able to use Start->Run
msiexec /x {EAEA0AD1-8470-4DC6-8D10-D7C152316C24}
or
msiexec /x {EAEA0AD1-8470-4DC6-8D10-D7C152316C24} /qn REMOVE=ALL

to manually uninstall the product? This does not work. It just returns immediatley (no errors). Interestingly if I build the project again (which auto-gens a new revision code), the above msiexec /x has an error that says
"The installed product does not match the installation source(s). Until a matching source is provided or the installed product and source are synchronized, this action can not be performed."

Am I missing something? How do I use msiexec to kick off an uninstall of a product?

thx

Jay, did you ever find a solution that does not entail performing a looking up to uninstall keys in registry? We use transform installs over here - and just as you have experienced, uninstallation can only be performed via Add/Remove programs.

There has to be some trick that we are missing, because Add/Remove programs simply uses the UninstallString - which calls into our installer. The instance product code must be gotten somehow in that case.