10 replies to this topic

[SkipSailors]

I use ISWI 1.52

The 37th cut of a product installation is not allowing an uninstall.  When selecting the application from the ARP dialog then pressing the "Add/Remove" button, it says,

"Another version of this product is already installed.  Installation of this version cannot continue.  To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."

My setup.ini has a CmdLine of "REINSTALLMODE=vamus REINSTALL=All" and I have a CA that sets the REINSTALL property empty on the condition "Not Installed".  (I am aiming for quiet upgrades)

I am in a network that is today having trouble telling what time it is.  DHCP is having trouble giving some IPs to needy machines.  I don't know that that has anything to do with it.

Any ideas as to why the error is happeneing and what I can do to make it stop?

TIA

[TimI]

Sorry Skip, no help for you there, but some comiseration. I just got handed the install here (IS 5.0). Best of luck.

Maybe you have some ideas on my questions in the 5.0 forum?

(Edited by TimI at 4:08 pm on Aug. 15, 2001)

[SkipSailors]

I find when I execute
   > msiexec /x <package.msi>
that it tells me another version of the app is already installed and I should use the ARP.  When I use the ARP, it tells me that another version is installed and I should use the ARP.  I am confused.  I thought  you couldn't get to this error using the /x switch.

This seems to stem from my using the IsCmdBuild.exe to generate the package.

This is resolved when I use the IDE to change the package code an present a new msi to the clientele.  A client can then install the package over the top of the offending package, then uninstall. fine.  This behavior is identical to the behavior I get when I have forgotten to add the "REINSTALLMODE=vamus REINSTALL=All" to the command line, but I examine the setup.ini and see that I have done so.

[Stefan Krueger]

Each time you build a modified version of your msi file you must assign a new package code.

[SkipSailors]

Each time I  build an msi I am changing the package code.  There is script code that does this.  To confirm, I have right-clicked and selected properties on each of these versions where the problem manifests, and the Statistics | RevisionNumber reports different GUIDs.

[houdeveloper18]

I got similar problem, to get the upgrade package do a fresh new installation on the machine without product preinstalled, I set REINSTALL to empty (and actually this is how it's suggested in some article for upgrading), but it gets problem during uninstallation. The error is 2711 and it sounds it has problem with the missing feature, that is the one we try to set empty during installation. Is there any solution to overcome this problem?

[SkipSailors]

Right.  You have a custom action sets REINSTALL to "" on condition that the Installed property is false.  That's what I do, and seems to work.

Does executing
   msiexec /L*v <log name> /i <package name>
offer any clues?

[houdeveloper18]

Skip, what you mean it seems to work? Did you get the same problem and find the way to resolve it?
I'd set REINSTALL empty if Not Installed, and this leads to the error 2711 during uninstallation.
The log file only reveals that this internal error come out right after CostFinalize.

[SkipSailors]

Yes, I mean my product installation does not exhibit a 2711 error.

[houdeveloper18]

but you got error during uninstallation, is it correct?
if yes then this is not acceptable solution because it cannot be uninstalled.
if no, then how could you get rid of this problem because REINSTALL empty seems create the missing feature problem while uninstall.

[SkipSailors]

I no longer have an error either in install or uninstall.  Several things I did help.  First, I made sure that every package has a new package code.  I wound up having to take extra steps (closing and reopeneing the project a couple of time) to make sure that the COM interface and the actual project agreed.  That was the main thing.

Other errors were artifacts of the development environment.  When the error occurs in a programmer's box, I use the the Windows Installer Cleanup Utility and immediately install the product.

If it happens in a QA box, I once again use the cleaner, then execute the test case from the beginning to verify that the test box doesn't have any spurious files or partial failed installs.  It has never reproduced in QA since I started taking the extra steps to make sure the package code changed, except when the test box has been misconfigured and a failed install is still out there.

It has never, AFAIK, happened in the field since the package rule code was enforced.