This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Deleting the cached MSI file during first-time install
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 03, 2010
06:20 PM
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?
I would very much appreciate any advice...
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?
I would very much appreciate any advice...
(8) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 07, 2010
10:45 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 07, 2010
07:07 PM
Hi Michael,
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 07, 2010
08:01 PM
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?
An altogether frustrating experience...
Where in the database could there still be a record of this? Or has the installer DB been corrupted?
An altogether frustrating experience...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 08, 2010
10:09 AM
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%.
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%.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
May 13, 2019
11:09 AM
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:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 08, 2010
04:04 PM
Thanks, Michael, for the advice.
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:
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:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 09, 2010
10:42 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 10, 2010
02:41 PM
Creating and running a minor upgrade finally flushed the little gremlin out! Thanks, Michael, for lending your expertise.