In the past I've build my setups using InstallAnywhere. I've now switched to InnoSetup as my new setup provider.
I need to remove the whole old installation before installing the new one. Innosetup recognises the old setup and executes the "old" uninstaller first, but the old setup doesn't recognise Innosetup's uninstaller. As the old setups are already out there, I can't change the configuration of these.
How to make InstallAnywhere recognise the Innosetup uninstaller, without being able to change the InstallAnywhere configuration?
Is there some kind of "standard way" that windows uses to check if the same application is already installed?
I've already tried to create the InstallAnywhere registry keys within Innosetup to "simulate" a previous InstallAnywhere uninstaller - without success.
I've found the location where InstallAnywhere stores its own custom "registry". Seems like all Flexera products use this mechanism.
There is an XML File C:\Program Files (x86)\Zero G Registry\.com.zerog.registry.xml that contains information about all installed components. Unfortunately the file format is not documented, nor it contains any reference to a schema Definition.
I basically ended up with a workaround: I am creating a "dummy" InstallAnywhere setup, that gets silently installed during the InnoSetup installation. It is used to do only a single thing: Beeing detected by an IA setup, and call the InnoSetup uninstaller during uninstallation.
Related
I am having trouble with my WiX installation in that I am registering a file extension but because you have to tie every component to a feature, I can't get the feature to install to "All Users"?
Specifically what is happening is I install the MSI under an admin account. The MSI is not located in a shared location that is accessible by all users. The extension appears to register for the other users however when other users click on the file (with the newly registered extension) to open it, it tries to look for the original MSI first to install a feature. If the MSI is found it will open the installed application like normal, otherwise it errors. For the admin account that installed the MSI, it does not ask to install the feature from the MSI (even if I delete the MSI before clicking on a file with that extension)
I have set the installlevel of all the features to "1" and set the TypicalDefault to "install" and InstallDefault to "local". The package is also set to install at the machine level.
Is there something else that needs to be set?
See if this helps: Troubleshooting unwanted self-repairs using the Event Viewer
Basically you need to understand why the repair is happening (which component key path ) and then remediate it. Alternatively you could wrap your MSI with a EXE (WiX Burn) and cache the MSI in a location that users can access if the repair is truly needed.
I had a windows installer install a service I created. I tested on my dev machine rather than a test machine. The application files no longer exist and the service does not show up in the list of Windows Services under Admin Tools. I am trying to remove the entry from the Add/Remove programs. I set the installer up with a custom action of uninstalling the service when the uninstaller is run.
Even with manually copying the files to the expected location and manually adding the service in to the list of services, the uninstaller fails. I can't manage to remove it from the list of add remove programs. How can I remove it from the list?
All the entries shown in the Add/Remove Programs panel are found in the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall -- you'll find your in a subkey named with a GUID (e.g. "{123409-adsf-1234...}") if it was installed from an MSI (in which case you probably want to re-run the MSI to remove cleanly you really should use msiexec /x {GUID} to uninstall, or double-click the original MSI package and choose "Remove") or it could be any name if it was installed with another setup tool.
Perhaps this will help:
http://setupanddeployment.com/cleanup/installer-cleanup/
http://setupanddeployment.com/cleanup/installer-cleanup-update/
We are installing several web sites using msi's as part of continuos integration tests.
For each build we want to uninstall the old msi and install a new one.
Problem is we do not have the old msi after the build server has done a get latest and rebuilt the system.
Is there a way in which we can uninstall the msi without having access to the orginal msi?
Yes you can, if you know the product code. Just type
msiexec /x [ProductCode]
on the command line. Or you could do it through the Add/Remove programs applet.
If you want to find the physical file, Windows actually stores a copy of the msi when it runs it - you will find it somewhere in your %WINDOWS%\Installer folder, but it will have been given a random name so could be quite hard to find :)
Alternatively if you don't know the product code (which you should) then try searching for your app name under the HKEY_CURRENT_USER\Software\Microsoft\Installer and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData registry keys, you will find the product code there. (quick hint: you can also search for UninstallString values in the registry).
I often get a problem with Windows Installer trying to uninstall a package, but it complains that:
The feature you are trying to use is on a network resource that is unavailable.
Is there a known means of uninstalling such packages when the original MSI is simply not available?
Please note that Microsoft has now released an official tool to resolve these issues, without the problems that previously existed with MSIZAP.
Microsoft Fixit: Fix problems with programs that can't be installed or uninstalled
Take a look at a tool called MSIZap released by Microsoft.
UPDATE:
MsiZap.exe has been deprecated for quite some time. Its use is unsupported on all recent versions of Windows, and it is considered a very unsafe tool to use.
I added a link to a newer Microsoft support tool designed to clean out installations, but this tool also appears deprecated at this point. I have removed the link from the comments section.
Perhaps try the tool linked to in saschabeaumont's answer below.
FYI, this post explains the root problem https://superuser.com/q/293542/245923
You can uninstall it using the product code:
msiexec.exe /x {your-product-code-guid}
You would obtain this code from the MSI itself, or whatever tool you are using to build the MSI.
Note that when you uninstall a product, it uses a cached MSI, since only the original MSI knows how to uninstall itself. When you use the product code, it uses the cached MSI from C:\WINDOWS\Installer.
Update, Stein Åsmul: There is a whole list of cleanup approaches here (recommended).
UPDATE:
This newer support tool can be tried on recent Windows versions if you have defunct MSI packages needing uninstall. This new tool appears to have been deprecated as well.
Perhaps try the tool linked to in saschabeaumont's answer.
It is not normal or standard MSI behavior to ask for the original source media - it indicates a badly designed MSI package. If you experience this with a vendor MSI it is highly recommended that you report the problem to their support team. Here is a more comprehensive explanation of the problem: Why does MSI require the original .msi file to proceed with an uninstall?
In most cases MSI packages can be uninstalled from add/remove programs from the control panel even if you don't have the original installation database for the MSI - the uninstall is run from a cached copy of the original MSI in the system folder %SystemRoot%\Windows\Installer (in some cases this cached MSI could be missing, see section 12 here for potential causes).
Earlier versions of MSI tended to trigger this problem (asking for the original installation media) more often (Office back in the day), and legacy MSI files can still cause uninstall problems that can only be solved using the msizap.exe tool (this tool is deprecated, outdated and no longer supported). This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe), both tools are deprectated (try the link to the new cleanup tool listed above).
Just for the record: If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one. There is a unique package guid assigned to each MSI file, so Windows will know if it is the right one.
Related answers:
wix - custom action dialogbox on silent uninstall of application
Uninstalling an MSI file from the command line without using msiexec
You didn't do something crazy like go to C:\Windows\Installer\ and delete the files in there did you?
One drawback of MSI files is you need the complete MSI file in order to uninstall or repair the application. Windows loves to store a copy of the MSI. It also renames the MSI file from a common name to a GUID with no table (that I can find) to map original names (example: Office2010.msi) to the new GUID so you have a PC with many GBs of wasted space that you can't delete. A machine that's not even 1 year old can easily hit 8 GB (example: mine).
There is an MSI cleanup utility from Microsoft, Windows Installer Cleanup Utility (deprecated tool, unsupported and unsafe to use - perhaps try this answer instead: Uninstall without an MSI file).
Or CCleaner can usually do this
Control Panel --> Add/Remove programs?
EDIT:
Your post mentions nothing about using add remove programs to uninstall the app, you said the "Windows Installer" (MSIEXEC - see the link below), which is not the same thing.
http://msdn.microsoft.com/en-us/library/aa367988(VS.85).aspx
Much searching has lead me to find several descriptions of how to create a bootstrapping msi, but these solutions all assume the msi is local or a standard Windows component. Is there a way to make an msi that downloads an installer (which is also an msi) with normal MSI or Wix code rather than by having the bootstrapper execute some non-native program to do so?
My experience with msi's has been it's not possible to run 2 at the same time. (could be wrong though)
What I ended up doing was to instead make an installer exe using Inno Setup (http://www.jrsoftware.org) and ISTool (http://www.istool.org) which downloads and installs the various msi's. With ISTool it's very easy to do.
I know it's not as chic or sexy as Wix, but it worked for me very well.
I would create a custom action that runs in the InstallUISequence. This would download the MSI if necessary (to the source folder), and then try to launch it as a nested installation.
Windows prevents two installs from being in the InstallExecuteSequence at the same time, so if you're looking for a silent install solution with a bootstrapper, you're SOL.
However you can start another install from the UI sequence, which is probably an OK solution as long as you advise your customers that certain other dependencies must be installed first if they're going to deploy via group policy or some other 'silent' method.
If it helps, I'm pretty sure you can also call MSIEXEC with a URL, eg. msiexec.exe /i http://some.domain/blah.msi /passive
I would suggest that you write a native app and have it run the first msi and then run the seccons msi. I wrote a blog on how to do this. Here is a link (http://blog.foldertrack.com/?p=45)