Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 2

Why do i have to cache the MSI file myself when windows does this ?

I have an installation setup.exe with few prerequisites and some merge modules. If i don't enable the Cache MSI Locally windows cannot find the MSI file when trying to do an repair eventhough windows has cached it in C:\Windows\Installer. I can see that if i rename the cached file in C:\Windows\Installer into the name that Windows expects when doing a repair it works. Why do i have to Cache the installer aswell as windows so there will be double MSI files saved on the machine. I suppose it should be possible for installshield to tell windows hey please look after the MSI inside C:\Windows\Installer where the file is, is it because the MSI in Installer folder has another name ? It should be possible to math the installed msi with the one in Install folder.

Labels (1)
0 Kudos
(2) Replies
Level 8

I am having a similar problem with uninstall. However, the solution was to cache the MSI locally but for some reason it is disabled in my setup.
0 Kudos
Level 11

Why indeed, when after MSI 5.0 it caches the whole entire compressed *.msi? Full packages that you can rename to the original package name and use just like the original installer?

Having been around for the evolution of this scenario, I'll tell you.

Prior to msiexec.exe 5.0, it used to strip the internal cab files out of the package when it saved it to c:\windows\installer. But of course, doing so changed the file hash of the package, and would break the display of the MSI's publisher in the UAC prompt when uninstalling or modifying the package (that is, if you'd signed the package with a signing cert). So a fix had to be put in place for Win7, because messing with signed packages is a security issue, not an installer issue.

That fix was to cache the whole package. Problem solved!

So if it's the full package, why can't you use it to repair instead of needing the original package?

MSI source resolution requires a package that matches exactly by name. So even if it registered c:\windows\installer as a valid source (which it doesn't by default), it won't use the package because the file name is randomized to not be human-readable.

I had the idea to create a symbolic link to a different location using the original package name and try using it to repair--and it worked great. I later found out some other guy came up with this a few years earlier. And of course, there's good reasons why this isn't a useful feature to bake into InstallShield (specifically, the SymLink API's don't seem to work correctly when done via automated deployment process under the SYSTEM account).

So yeah... Cache the install locally is your best bet still. Crazy as it is.
0 Kudos