Deleting the cached MSI file during first-time install
Hello,
Is there a way to delete the cached MSI file during an initial (clean) install? Bear with me here: I know that I can configure the installation not to cache the msi on the local machine, but I see that deleting the cached file after the first-time install doesn't cause problems for initiating maintenance mode; the msi still gets cached when setup.exe is called, allowing it to execute. (I am using Installscript MSI.)
What I've tried is to use an Installscript CA to delete the application's sub-folder under [LocalAppDataFolder]Downloaded Installations, to no avail. I am placing the CA in the Installation Execute sequence after InstallFinalize.
The reason I want to do this is that some end users have complained about the disk space these use.
So is it possible to do this during a first-time install? Perhaps more importantly, is it wise to do it?
If you don't want these files, how about you disable their use on the Setup.exe tab of the release configuration (the option is Cache MSI Locally)? Mind you that if you are distributing a compressed setup, then without these files, any maintenance operations will likely give confusing error messages unless they are launched from the original setup again.
Thanks for the feedback. Actually, I find that I still encounter that error when repairing in such a case, even when executing the original setup. And I think most of our end users are going to run such a maintenance from Add/Remove programs anyway, so I'd like to avoid hopelessly confusing them. 😉
I think that my problem is where in the execute sequence I am placing my custom action (originally it was after InstallFinalize). However, moving the CA to what seems to be a logical part of the execute sequence causes an Error 2762 ("cannot write script record").
In executing this bit of Installscript, where in the sequence should I place the CA?
Ok, I'm getting this error 2762 during installation even after deleting the CA from the project file and rebuilding the cab! I see in the msi log that it is still calling the CA, even though it's (ostensibly) gone. What is going on??
Where in the database could there still be a record of this? Or has the installer DB been corrupted?
I'm not sure why rebuilding the .cab file would make any difference to the custom actions; those are stored in the MSI tables of the .msi file. If you're not testing on a clean image, it's also possible that the previous attempt did not uninstall, leaving you in some weird small update scenario; those are never pretty. If you want to look for stray records, use the direct editor and look at the CustomAction and Install*Sequence tables, and possibly the Binary table. If you want to check for lingering installations on your test computer, perhaps use InstallShield MSI Sleuth.
Again, it doesn't make sense to install from a cache location and delete it; if you're going to do this, just turn off the option. Then the compressed bootstrap will extract the .msi to %TEMP%, install it, and delete it for you. But more important, launching from Add/Remove programs is not going to avoid the confusing scenarios. Your users would have to launch from the original compressed bootstrap so it re-extracts to %TEMP%.
I have a cached MSI file for the install and that was done because one user would log in to a Windows 7/10 PC to install and another would log in to do the uninstall or an upgrade. This caused issues and Flexera said to cache the MSI. Now I have the same problem as Mescalero. I just want to remove the most recent cache folder when I uninstall. I have tried a CA but it seems to never fire on an uninstall even though my condition is REMOVE = "ALL:
How to get out of this pickle on my machine, however, I'm not sure. I don't see mention of this CA in any of the msi tables, but it is reliably mentioned in the msi log as the reason for install failure. :confused:
Make sure you're looking at the same .msi file that is mentioned in the logs. If it's not the same one (for example it's a cached one) try uninstalling it with msiexec /x {product-code-here}. If that fails you can try recaching a small update or minor upgrade to overwrite it on your machine (msiexec /i new.msi REINSTALLMODE=vomus). Or in a worst case scenario, you can try running the Windows Installer Cleanup Utility (msizap) and blowing away the cache information (but not the files) from your test machine.
