4 replies to this topic

[GuySmiley]

Hi.. I am trying to write an upgrade for a previous installer that was incorrectly written.

the old installer did the following:
1) installed a folder & files as a component (a keypath-less component as per IS dynamic linked files)
2) copied folder & files to 4 other locations on the target machine as part of a CA (didn't know about the DuplicateFiles table at the time)
3) deleted the original folder & files as part of the same CA

.. while you all gasp at my audacity may I just say that MSI is a difficult technology to pick up as you go..

anyways, despite the horror of this practice I still need to upgrade this old package. The problem is that during the RemoveExistingProducts action of the upgrade MSI is determining that it needs to reinstall this component, then complaining that it has no access to the original source.

My question is: is there a way to force MSI to not attempt to install these files as I am trying to remove that old package anyway? I need to do this even if it results in a screwy WI registry at the end of the removal..

thanks for any help,
gs.

[luke_s]

The problem is that your old installed is trying to Resolve the original source during the RemovExistingProducts (ResolveSource action did not have a condition set on it).

I had a similar problem and the only way to fix this that suited my needs was to hack the msi file that is stored on the system for the old installer by using a wrapper for our new install.

Maybe you could just create some code to prompt the user to uninstall the old package before they re-install?

[GuySmiley]

thanks luke.. yes I don't think that asking the customer to manually remove the previous install is going to be acceptable so I'm going to either have to hack the cached .msi (*shiver*) or figure out a way to get the removal to complete without errors by passing in command-line args.

I discovered that since the component in question has no key file I can just create the component folder on the machine and it will avoid the error message I was seeing... this is when I remove the product by invoking msiexec from the command-line. Unfortunately when I try to do the same thing via RemoveExistingProducts of my upgrade package I am still getting a "can't access source" error.. I don't know what the difference is as I can see by the log file that it is using the same command-line that causes no errors when I invoke it manually.

Does anyone know of a way to log the nested uninstalls that occur as part of RemoveExistingProducts? I have the pared-down log that appears in the upgrade package log, but it doesn't contain the detail I need to find out what's going on during the removal..

thanks again for any help,
gs.

[luke_s]

If you log the install with verbose logging, it should give you some information about the nested install.

[GuySmiley]

I finally resolved this issue.. an improperly conditioned action was actually executing before RemoveExistingProducts which would delete a file, causing the nested uninstall to attempt to repair the feature by reinstalling it.

Once I fixed the condition I was able to make it through RemoveExistingProducts without errors, following which I execute a custom action that cleans up any left over registry from the previous package, since the Windows Installer is very confused at this point and needs some help. :)

thanks all for your help.

gs.