Installer using $PatchCache$ as source folder

[alhenderson]

Morning All,

I've been wrestling with a problem with our installer for a couple of days. It is a Basic MSI project, and for every build we change the Package Code, leaving the product code and version untouched (thus making this a 'Small Update" in installer parlance, I believe). I noticed the other day that, following an upgrade using the latest installer, the binaries in my bin folder were not up to date. The were all showing a version number that was some 2 months old. On closer inspection of the MSI log I realised that it was getting the source files from a '$PatchCache$ folder, i.e.:

C:\Windows\Installer\$PatchCache$\Managed\\

I've done much searching of these forums and other places and am no clearer on:

1. Why did the version from a couple of months ago get cached in the first place?
2. Why is the installer now deciding that it should use this cache?

The answer to #2 may be that the mere presence of the cache is enough to ensure it is always used. I'd like to think I'd have noticed before now, but the reality is that I may not have done. So, question 1 is possibly the most pertinent.

I was hoping to not have to delve too deeply into the reasons for this, I wrote an installscript function to delete these files, but it failed to do so with an ACCESS DENIED (0x80070005) error (if I try to do it in windows explorer then I'm asked to provide admin privileges - I run the installer as administrator, but that doesn't seem to help).

So, looks like I'm back to trying to figure out why the stuff got cached in the first place. I have only seen this behaviour once before (and only on one machine) so I don't think that my installer is always cacheing it's binaries.

Is anyone able to shed any light on this situation?

Thanks,
Al.

[alhenderson]

Another piece of information from the MSI log. I notice that the command line is:

Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 SETUPEXEDIR=xxx SETUPEXENAME=xxxx CURRENTDIRECTORY=xxx CLIENTUILEVEL=0 CLIENTPROCESSID=11516

My understanding is that for a minor upgrade, the Package Code *and* the Product Version have to change. I don't believe that the Product Version has changed. Does the IS_MINOR_UPGRADE have some bearing on this problem, or is that a red herring?

Al.

[alhenderson]

In case anyone's reading this looking for an answer, I don't have one 😞 I ended up writing a custom action to look for the patch cache folder and rename all the binaries in there to prevent them being used by InstallShield. Was unable to delete them - did not have permission. Not nice, feels like I'm fighting InstallShield, but in the absence of any kind of indication from IS as to exactly what it was doing, I didn't have a lot of choice.

Next time I need any kind of installer I'm going to write a powershell script..

Al.