MSI cache

[chriz78]

I'm kind of new to InstallShield and I mostly just use it for repackaging some apps for deployment through SCCM. Anyway, I noticed that the first time a user runs certain MSI based applications, the application tries to configure itself, and looks for the source MSI. If it's no longer in the ccmcache folder, it fails to run and asks to browse for the MSI source. I know many applications cache the MSI into folders such as C:\Windows\Installer or C:\ProgramData\Package Cache. How do I tell InstallShield to cache the MSI somewhere? The only setting I found is in the release section, but that only is for programs using setup.exe, and I try to make my installs as only MSI's. If there is a setting, is there a default or standard folder that the MSI should be cached to?

[chad_petersen]

If your using the "Basic MSI" as Flexera calls it then yes, your MSI should be cached to the C:\Windows\Installer folder. However, it will not have the file name of your MSI. Instead it will have a system generated hex number in place of the name of your MSI file. It will still be an MSI file, but the filename won't be one you recognize. If you sort your C:\Windows\Installer folder by the "Date modified" column, with newest at the top, and then run your installer to completion then refresh your C:\Windows\Installer folder the newest MSI file should be from the installer that you most recently ran.

That's how it works for me, at least.

There's a bit more too it than that, like how it stores the entry in the registry to map your MSI to the one in the cache, but it gets a bit more involved with GUID scrambling going on. I have an unscrambler myself that I wrote which allows me to verify a few things, but it's all Microsoft stuff there.

I hope that helps some.

Chad

[chriz78]

Hi Chad, thanks for the explanation. Yes, it looks like it is storing a renamed version of the MSI in C:\Windows\Installer. So then the question is, why does Windows Installer not look for the MSI there when it tries to configure or repair? I'll have to do some more searching for answers on that, but I'm guessing I'll have to look into that GUID unscrambling.

[chad_petersen]

To reduce the footprint of the cached MSI files all "Files" listed in the File table in the MSI are typically stripped out. The cached MSI is used primarily for bookkeeping and uninstalling and since it does not have the actual files in it then - in order to do a Modify or Repair you commonly have to provide the initial MSI from the source media.

The C:\Windows\Installer folder is a hidden folder that we are not supposed to know about (Shhh, don't tell anyone it is there). Lol.

Chad

[chad_petersen]

A couple of people sent me a private message asking if I could explain a bit more.

Consider the MSI where none of the files are compressed (embedded) into the MSI - where all the payload files are sitting in a folder with the MSI - uncompressed

If it went to cache this MSI then all of the uncompressed files would have to likewise be copied to the C:\Windows\Installer folder. This would absolutely fill up the cache folder with files that are not the MSI itself, but are the deliverable files.

If your Payload is very large then this can be a problem because not only do you have to have space for your install, but you would have to have double that space in order to cache everything also.

Microsoft decided a long time ago, when hard drive space was at more of a premium, that they would only cache the MSI itself. Probably not a bad decision in hind sight.

I hope that helps some.

Chad

[chriz78]

Thanks Chad. I also found out that even if the MSI located in C:\Windows\installer has all the files that it needs embedded into it, Windows installer still won't even attempt to use that file for repair or initial configuration. It's only used for uninstalling (and bookkeeping as you said), which is too bad. This article explains it:

https://www.symantec.com/connect/articles/reducing-windows-installer-disk-wastage-windows-7

[chad_petersen]

That's a great article. You can see in step #3 the GUID scrambling that is done. It's a switching around of the hex pair ordering. My utility just does that same thing when you feed it a known GUID. Not a biggie, just a tool.

Thanks,

Chad