tags:

views:

45

answers:

2

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?)

+1  A: 

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

Christopher Painter
My question is - how do I stop this happening on production machines, I know how to fix my machine! :-)
Kragen
"Do we need to keep copies of all versions of the installer ever installed on a machine?"Um, yeah. Don't you already keep a copy of everything that goes into production? I know we have a Configuration Management System that makes sure we do and everywhere it was delivered.If your question is WHY this is happening and not how to get out of it, then log the uninstall to see why it's asking for the MSI.
Christopher Painter
+1  A: 

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.

Rob Mensching
My question is - how do I stop this happening on production machines, (or how is my MSI "broken") I know how to fix my machine! :-)
Kragen
Look at the verbose log file to figure out why the original source is being required. You've probably got a bug in your MSI somewhere that is forcing it to want the original source during uninstall. Until you fix that, you'll need to have the MSI available... which is massively annoying. :)
Rob Mensching

related questions