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: Why do i have to cache the MSI file myself when windows does this ?
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
‎Feb 09, 2017
02:10 AM
Why do i have to cache the MSI file myself when windows does this ?
Hi,
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.
donnib
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.
donnib
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 18, 2017
09:49 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 18, 2017
12:49 PM
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.
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.
