Wix / MSI : Unable to uninstall

Question

I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:

The feature you are trying to use is on a network resource that is unavailable

with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)

I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.

Is this the case?

What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)

Answer 1

The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:

msiexec /fv path\to\your.msi /l*v i.txt

That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.

Answer 2

One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)

That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.

Now there are several ways out of this pickle:

1. Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\\Installer . CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.

or

2. Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.

or

3. Reimage your workstation

Answer 3

If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.

For example:

• Locate the MSI file in %WINDIR%\\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
• Open the msi file with Orca.
• Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
• Save the msi and close Orca to release the lock on the msi file.

Answer 4

1 - Have you experimented with " run from source " during installation?

This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: " The feature you are trying to use is on a network resource that is unavailable " if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.

2 - Are you running script custom actions ? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?

3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.

4 - Are any of your userprofile folders redirected to a network share?

5 - Are you installing anything directly to a folder on the network ?

There are plenty of other possibilities.