3 replies to this topic

[jonathan2002]

I have a basic MSI project, which is not usiong any InstallScript at all. Admin rights are reuqired to install the software, which installs and removes OK. The software is installed for all users, registry entries go in LOCAL_MACHINE.

The problme I have found is that if I install as one user (myself, part of the local network) and then log off and log on as an admin user of the machine itself, and then run the install, it first of all doesn't detect that the software is installed. To get round this I added code (to the installer DLLs I have written in C++, that do the additional installation tasks) so that it now detects if the software is installed already and if so goes into the Maintenance sequnece. Finally, to force it to remove the software I added a condition to the ReadyToRemove dialog so that it sets REMOVE to "ALL" when the Remove button is pressed.

This final change has had the effect that now, when removing commences, the install generates an error message:

"Internal error 2755. 1605, {the path to the temporary file in the C drive whereb the temporary .msi file is created}"

The msi certainly exists at this point (the project is built as a setup.exe file).

This error is similar to another one noticed recently when the user tries to remove the software from the Add/Remove page of the Control Panel.

All of the above has been observed on Windows XP. No other OSs have been tried yet.

What is causing this error? NB. the user has admin privileges when the remove is being run.

Generally, I want it to be the case that if software is installed with one admin user, it is detected and repaired/rtemoved by any other.

[Glytzhkof]

If your product is registered per machine (accessible to everyone) it will not be possible for other users to start the same install and not go into maintenance mode. If the setup continues without detecting the previous install the setup either has a different product code than the one you installed, OR your setup is registered as a per user setup. How a setup is registered depends on the ALLUSER property, please check it to determine how the setup is really installed.

Note: If there is no good reason to install per user, I usually disable this feature, and force a per machine install by setting the ALLUSERS property in a custom action. Some merge modules also requires a setup to be installed per machine (such as the buggy SOAP merge module).

[jonathan2002]

I thought I had ALLUSERS set but I'll check that.

I tried this again building the project as a set of files rather than a setup.exe, but now i get the same error, only referencing the .msi in the actual build folder rather than a temporary folder.

[jonathan2002]

That does the trick - I just assumed I had ALLUSERS set. I must have got this proj3ect mixed up with another one (