$PatchCache$ files on minor upgrades

[Sairen]

I've had this problem a couple times in the last year or so. (In fact you may think this post looks suspiciously like one in the 2010 forum.)

I'm troubleshooting s a Basic MSI installer, and we're on about the 7th major version of it. So it's been around awhile, pretty stable. We wrap the MSI in Setup.exe and distribute it like that.

We do major upgrades when changing the 1st or 2nd version number, and for everything else, including daily builds, it's updating according to the rules of a minor upgrade. We have never put out patches for this product.

Today, I had a few people tell me that a particular exe we distribute wasn't updating properly. I found this in their log file:

Source for file 'filemonitor.exe.0BC73C49_D315_4459_BD9C_12CAEDE59903' is uncompressed, at 'C:\Windows\Installer\$PatchCache$\Managed\3382210BEFD77CD419638F493C5C259C\6.5.0\'.

Versus this in a log file from a machine I tested, working Source for file 'filemonitor.exe.0BC73C49_D315_4459_BD9C_12CAEDE59903' is compressed

I have discovered that most of the files that end up being cached belong to merge modules. If I rename the file stored in the patch cache, the next time the product is repaired or updated, then the corresponding "real" files in the product location are updated correctly. It's not the worst workaround, as they go, but it's still not pretty.

I have several questions, in descending importance, though some might be intertwined...
1) How do I fix these machines so that the next time they update, it fetches the file from the installer package and not this cached machine. Is it safe to delete the folder structure under $PatchCache$?
2) How do I stop it (the machine? the installer?) from creating this patch cache again?
3) Why did it create a patch cache for this product when we've never put out a patch
4) Why are patch cache copies made for *these files* in particular?

Any help or insight would be much appreciated.

[joshstechnij]

Unfortunately, we don't have any insight as to how files would normally be cached by Windows Installer in the patch cache beyond what is publicly documented on MSDN.

However, since these files belong to a merge module, is this module shared across other MSI packages? If so, were any of these MSI's patched at any point? Shared components contained in merge modules could potentially be part of the cause of this type of behavior. Though this is not directly related, you may try setting the "Multiple Package Shared Component" setting to Yes on the components containing files that are being cached in the patch cache to see if this changes the behavior. If this merge module is not shared across multiple MSI packages, this setting will have no effect at all.

[Sairen]

Josh, thank you so much for your reply!

I wonder if I could trouble you to post the link to whatever is publicly documented on MSDN... I wasn't able to find much that seemed useful when I went looking!

The module is shared by multiple MSI packages, but none has ever been patched. I will try setting the "Multiple Package Shared Component" value on the files in the merge module that are being cached. However, two things will make it somewhat difficult to confirm a fix. First, any file appeared to be fair game to end up in this PatchCache folder, not just a single one or two. Second, it appears at this time to be an entirely random occurrence; I am unable to reproduce at will.

I appreciate your suggestion. If you run across any more information or anyone else seeing this, I hope you'll update this thread further! 🙂

Thanks!