I'm writing a new installer for our legacy software. The installer was originally built with InstallShield Professional 6.40, and I'm now building it in Inno Setup. Because of major changes in the software's infrastructure, I need to first uninstall the old one so that I can perform a fresh installation using the new one (using Inno Setup).
The old version was installed in the drive's root (C:\SoftwareName\) And now I'm moving it to its appropriate place in the Program Files - as well as changing the registry key names. So although it's the same software, it's really treated as a completely different software.
I have found the entries in the registry for the old installation:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{[OUR GUID]}
And in here, there is an entry for uninstall information in UninstallString:
RunDll32 C:\PROGRA~2\COMMON~1\INSTAL~1\engine\6\INTEL3~1\Ctor.dll,LaunchSetup "C:\Program Files (x86)\InstallShield Installation Information\{[OUR GUID]}\Setup.exe"
The second part of that, I know I can execute to launch the "Modify / Uninstall" wizard. But this needs to be automated, showing only the progress of uninstalling.
I've found the following links:
http://www.symantec.com/connect/blogs/various-silent-parameters-uninstalling-installshield-applications
http://pic.dhe.ibm.com/infocenter/pcomhelp/v6r0/index.jsp?topic=%2Fcom.ibm.pcomm.doc%2Fbooks%2Fhtml%2Finstall_guide12.htm
But these appear to refer to newer versions of InstallShield. Our installation was with a very old one (6.40). I've managed to use that wisdom at least to initiate the uninstall like so...
RunDll32 C:\PROGRA~2\COMMON~1\INSTAL~1\engine\6\INTEL3~1\Ctor.dll,LaunchSetup "C:\Program Files (x86)\InstallShield Installation Information\{[OUR GUID]}\Setup.exe" -10x9 -uninst -s -w
But it still gives a yes/no prompt if user wishes to uninstall...
This process is supposed to...
Run silently with no wizard or user prompts
Display just the progress of uninstall
Wait until uninstall is complete before returning
But I have no luck accomplishing those things.
What's the appropriate way to perform this uninstall?
Related
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
I am having trouble uninstalling a package from Windows 7 that I myself have created with InstallShield.
Running remove program from control panel only got 1/2 way before it aborted and rolled back.
Funnily it reported the problem being one of my install steps, not one of the uninstall steps.
Frustrated I used the Windows Install Cleanup and the package is no longer listed under Remove programs.
However when I try to run the installer once more it reports that a previous version of the software must be uninstalled before it can proceed.
I was guessing that the Unique ID was still present in the registry but is not.
How exactly does windows determine that a previous version of the software is installed on my machine?
The best solution to an uninstall issue that prevents the product from being uninstalled is to debug the issue (often a custom action) and fix it or delete it, then rebuild the MSI with the same ProductCode. Then reinstall it with a command line:
msiexec /I [path to msi file] REINSTALL=ALL REINSTALLMODE=vomus
which updates the product in place and the re-cached fixed product will now uninstall. Otherwise (because you can't recreate the MSI) it is possible to go into the cached MSI in C:\Windows\installer and change the MSI manually with Orca, conditioning CAs not to run, for example. But you need to know what you're doing.
In other words and unfortunately, it would have been better to get the uninstall issue dealt with before resorting to the installer clean up utility, which I believe may no longer be supported because it doesn't completely clean up the system.
Your best approach now is to change your ProductCode, UpgradeCode and PackageCode because they'll be among the items on the system that Windows will use to see that your product is already installed. This stuff is in the registry, but it's obfuscated (rearranged guids) and scattered around.
How to check that oldest version of application was installed during process of installation new version? What do I mean? I want before start installation start check process with dialog "please wait", if my installation found old version I can provide dialog "update or delete old and install new".
How can I do it?
Thanks.
I'm not sure whether this can be done at all, as running an InnoSetup-setup always assumes that you want to install new or update an existing installation. I don't think you can switch a setup from "installation mode" to "uninstallation mode" upon user's choice as you'd like it to do.
InnoSetup works differently than Windows Installer at that point. It has a separate installer and uninstaller as opposed to Windows Installer, which "contains both".
If you want that feature, you may want to look into Windows Installer XML (WiX), which creates MSI setups and can do exactly what you're looking for.
EDIT
First of all, thanks for the downvote. I don't quite know why anybody would downvote a perfectly reasonable reply, but I guess I'll have to cope with it.
To answer your comment about BeforeInstall: If you read the documentation you will notice that BeforeInstall is called before an item is installed. Quote from docs:
The name of a function that is to be called once just before an entry is installed
What you want to do comes down to:
Decide whether the user should be able to choose if he wants to install or uninstall when setup is run
install or uninstall depending on user's choice
What I'm trying to say is that as far as I know you can not switch from installation mode (setup.exe is run) into uninstallation mode (uninstall.exe is run) from your installation script.
InnoSetup assumes that running Setup.exe is equivalent to wanting to installing or upgrading. I the user had wanted to uninstall, he would have run the uninstaller, not the setup.
I have an installshield installer that works fine under normal circumstances. But when I run it while a particular software is running, the installer asks for a restart at the end.
Now on some research I have come to learn that a restart is asked only when the installer wants to modify files that are currently locked by other processes.
Is there anyway that I can find out which is the file installsheild wants to modify? (but cannot because it is locked by another process)
I would also like to know if it is only file modifications that affect the restart/no restart or is it also associated with registry key modifications.
You can use WhyReboot after the setup, it will show you pending reboot file and registry keys that could not be modified during the setup.
You tagged your question with "windows-installer", so I'm assuming you're using InstallShield to author an MSI installer.
Run the other software app, do a complete log of your install, like:
msiexec -i file.msi -l*vx test.log
In the resulting log, look for all lines containing "RESTART MANAGER". You will get more data on what is prompting for the reboot.
In my case, my installshield project had a "RebootPrompt" User Interface at the end of the Installation sequence with a condition "NOT INSTALLED". So all new installations would always show that Reboot prompt even if not needed.
As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?
I can only see disadvantages to that:
not resilient to network changes.
not resilient to local disk changes.
unexpected by users.
typically requires users to leave their desk and start a crusade to get the correct CD.
kind of proves installations are not self-contained.
promotes the use of unsafe tools such as msizap.
which in turn promotes the "next time I'll just use a zip file" mentality.
Could someone shed some light on this?
Fix Broken Uninstall: You can try the newest FixIt Uninstall tool from Microsoft if you have problems uninstalling an MSI. And one more link: Uninstalling an MSI file from the command line without using msiexec (a plethora of different ways to uninstall an MSI).
UPDATE:
This new support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported msizap.exe).
Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).
Why are you asked for the original installation media?:
The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use MsiZap.exe to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try this support tool instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).
Related answer:
Uninstall without an MSI file
In addition to this answer, perhaps this article on various ways of uninstalling MSI packages is of interest. It is a rather popular article with a high number of views:
Uninstalling an MSI file from the command line without using msiexec.
There are a few reasons for keeping the original msi:
The uninstaller uses it to know what files and registry keys were installed and make sure they are all cleaned up.
The msi may contain special uninstall actions that need to be performed.
It allows you do to a 'repair' operation from the Add/Remove Programs menu, regardless of whether or not you saved the install file yourself.
The normal way of things is for Windows to keep the file cached for you, so you don't have to think about it. See your %WINDIR%\Installer\ folder. The only reason it would ask your for the original msi is if something is wrong with the saved file. This addresses most of your concerns, though it does raise a new one (disk-space).