6 replies to this topic

[Gareth at Serif]

Hi guys,

Here's an enigma for you to consider over the weekend.

A custimer of ours has successfully installed one of our applications to an external hard drive that mapped itself to F:\. This drive has ceased functioning and they would like to re-install the application on an alternative drive. The problem is that since the package is already known by the OS as being installed, it gives the user options to remove/modify/repair. Choosing remove (or any I'd imagine) causes CostFinalize to fail with:

"Error 1324. The folder path '<blah, blah>' contains an invalid character."

I'm assuming that the action is failing to evaluate the contents of a drive that no longer exists. So how can he get it off his system? Could it be as simple as creating a temporary drive mapping so at least it could exist and satisfy the costing? Or is there a secret msiexec switch you can through to dump the install from the OS and allow a fresh install from new?

Thanks for any suggestions in advance,
Gareth

[Gareth at Serif]

By way of an update on this issue... we've tried creating an F:\ drive mapping and the problem persists. If it's any help, the path quoted in the error message doesn't have any drive letter, just the name of the folder the application was installed to - which was on the root of F:\.

Cheers,
Gareth

[Glytzhkof]

Did you try the windows subst command? (map path to drive letter) I have had success with that in the past. Other than that there is always msizap.exe and the "Windows Installer Clean Up" front end GUI for it. It allows you to unregister an installed MSI file by brute force (simply removing the MSI database registration entries - no file or registry cleanup is done apart from this).

More details:
http://support.microsoft.com/kb/290301

[Gareth at Serif]

Thanks for that, it did the trick.

[Glytzhkof]

Make sure to condition the "ResolveSource" standard action with "Not Installed" so that it doesn't run during uninstall (unless you need it to run). I believe running it could potentially trigger source dependence for uninstall (though this might not be the actual problem in your case).

In most cases uninstall is run from a cached MSI package with a randomized name in %SystemDrive%\Windows\Installer . The MSI cached here is stripped of any CAB files and only contains the bare-bones MSI tables. This is generally sufficient for uninstall to take place without source access.

[Gareth at Serif]

Cheers, I'll look into some kind of future improvement along those lines - the failure was happening as part of the costing though. It's not been made clear to me as to how the UI manifested itself to the user for me to get a best idea of what was so confusing about the nature of the issue, but I hope to replicate it and see for myself and follow your advice then.

Gareth

[Glytzhkof]

I am curious what worked btw? subst or msizap?