nickchiu51881.5524897112211511E12 asked a question.
FeatureRemoveAll() got a pop-up error message on Windows 7
It seems FeatureRemoveAll() is OK for Vista 32-bit/64-bit and WinXP 32-bit/64-bit while removing the package from Control Panel (it's supposed users install the setup program from USB or CD and don't copy the setup folder onto Desktop or disk drive); however, it is not for Windows 7 RTM. An error message will be come out during un-installation as below.
The installation source for this product is not available. Verify that the source exits and that you can access it.
C:\Windos\Installer\I6cfbb.msi
The following are the scenario:
1. Install the driver package using a USB or CD.
2. Remove the USB or CD when finish the installation.
3. Reboot the PC.
4. Remove the driver package from Control Panel.
5. You will get the similar error message above.
6. You might need to execute twice or more than twice installing/un-installing process in order to get the error if you do not find the error at the first try.
The issue with InstallScript MSI projects is resolved with InstallShield 2010. However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall.
I'm working with INS2008 and I ran into the exact problem you described. I'm just wondering what you meant by this
"However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall."
How do I accomplish this in my installer?
In another post a user said this problem could be avoided by building the installer in custom type and that has worked for me as well. However, when I make it into a Windows Self-extractor (necessary for my purpose), the same problem appear again. Any idea why?
Thanks in advance.
The above situation can be avoided by running another MSI package because the cleanup performed during the unrelated install will remove the transforms previously marked for clean-up. The unrelated installation must be a Windows Installer based installation to ensure MSI's clean-up process is performed. Non-MSI installations (pure InstallScript, self-extracting zip, etc.) do not invoke MSI and would therefore not allow the MSI file clean-up to run.
Note that this issue occurs only with InstallScript MSI projects in InstallShield because of a long-standing issue that resulted in a leaked handle to the MSI package opened by the InstallScript engine, causing any transforms and the MSI package to be locked at the end of the installation when MSI tries to clean up these files. Due to changes in MSI in Windows 7, this can now cause the behavior described above.
Thanks so much for your reply.
So should I be expecting a fix patch for my IS2008? Or what do you suggest I should do for our next software release? If possbile I would still like to keep using this InstallScript MSI project which we have been using for over a year. Is building the installer in custom type my best bet? Or is there a way I can build the installer as a compressed file and still avoid this issue?
Note that this issue does not tend to appear in typical use cases (meaning a normal user should rarely, if ever, see it) and has usually been reported as appearing in test environments where a setup is repeatedly installed and uninstalled.
You could try to block the setup from running on machines that have the MSI registry key/value set indicating it needs to clean up files left behind on a previous uninstall; however, this would then rely on looking at an undocumented registry key and would provide little benefit since getting past the block would require a user run a completely unrelated MSI based installation.
The issue with InstallScript MSI projects is resolved with InstallShield 2010. However, you can avoid this behavior by running some other, unrelated MSI package before installing your product for a second time after the first uninstall. "
We upgraded to Installshield 2010 and this problem still exists.
Trying to uninstall an installscript MSI on Windows 7 gives us this:
This is due to the issue caused with MSI 5.0 and the original issue in InstallScript MSI projects built with IS 2009 or older. Installing and then uninstalling these projects puts the machine in a state that will then cause the behavior when installing another build of an MSI that has the same product code. Either the product code of this project needs to be changed, or, as mentioned earlier, another unrelated MSI installation (i.e. an MSI package with a different product code) needs to be installed to correct the machine state before running a newer build of your installation package.