Installer not overwriting an old DLL that was branched for a client

Question

I have an InstallShield 2012 Basic MSI project that I have been maintaining for our company. I am not a trained InstallShield developer (merely the lowest [at the time] on the totem pole), but I've picked up enough over the months to get everything running smoothly from version to version.

Recently one of our customers insisted we fix a bug in an older version of our product that we'd already fixed in the newest release. We don't normally create patches since the full installer doubles as an updater, but in this instance we complied, created a branch at the version they were at, and sent them an update patch. Only one file was included in that patch and it had the same version as the file it was replacing. All was well.

Today that customer wishes to upgrade to our latest version. Effectively we are merging their branch back into the mainline, and since their branch has no extra components or client-specific code I thought we could simply give them our regular installer and have that overwrite everything. Not so...

When I replicated their branched install and tried to update the files the installer runs successfully and replaces everything BUT their branched dll. Tinkering with 'omus', 'amus', force overwrite, etc. changes nothing. Deleting the file beforehand does nothing. No matter what I try the branched dll remains and the log looks something like this (names changed to protect the guilty, versions and guids left intact):

DLL that updates correctly:

Executing op: RegisterSharedComponentProvider(,,File=dll_that_works.r1,Component={B4F132E0-6C2A-4138-990B-16B991F8C54D},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=SY2F9C~1.DLL|dll_that_works.dll,SourceCabKey=dll_that_works.r1,DestName=dll_that_works.dll,Attributes=16384,FileSize=51584,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:\inetpub\wwwroot\Service\bin\dll_that_works.dll;    Overwrite;  Won't patch;    REINSTALLMODE specifies all files to be overwritten
Source for file 'dll_that_works.r1' is compressed

Branched DLL that does not update:

Executing op: SetSourceFolder(Folder=C:\Windows\Installer\$PatchCache$\Managed\CA6D1F2B4A599A44A92536A1A31D3498\1.1.1)
Executing op: RegisterSharedComponentProvider(PatchGUID={EC6657A6-01A1-4AFC-86F9-1F4BF5F15481},MediaCabinet=#PCW_CAB_Family1,File=branched_dll.r,Component={74531F91-82A9-421D-A227-15DDDEDFC2FA},ComponentVersion=1.1.1.195,ProductCode={B2F1D6AC-95A4-44A9-9A52-631A3AD14389},ProductVersion=1.1.1,PatchSize=35952,PatchAttributes=0,PatchSequence=10000,SharedComponent=0,IsFullFile=0)
Executing op: FileCopy(SourceName=branched_dll.r,SourceCabKey=branched_dll.r,DestName=branched_dll.dll,Attributes=0,FileSize=225664,PerTick=65536,,VerifyMedia=0,,TotalPatches=1,,,CheckCRC=0,Version=1.1.1.195,Language=0,InstallMode=130023424,,,,,,,)
File: C:\inetpub\wwwroot\Service\bin\branched_dll.dll;  Overwrite;  Smart patch;    REINSTALLMODE specifies all files to be overwritten
Redirecting file copy of 'C:\inetpub\wwwroot\Service\bin\branched_dll.dll' to 'C:\Config.Msi\PTB2C9.tmp'.   A subsequent patch will update the intermediate file, and then copy over the original.
Source for file 'branched_dll.r' is uncompressed, at 'C:\Windows\Installer\$PatchCache$\Managed\CA6D1F2B4A599A44A92536A1A31D3498\1.1.1\'.

This is a little out of my depth. Near as I can tell it is trying to patch the branched DLL, can't do so, and throws the file into a temp directory for some reason (I couldn't find details on what exactly 'smart patch' means). I've seen that happen with patches that were applied to the wrong version, but this isn't a patch! It's a regular installer being run with REINSTALLMODE=v(oa)mus and REINSTALL=ALL. It should just see the older version, see that it has a newer version embedded, and blow the old version away.

(On a whim I tried updating the DLL manually instead of using the updater we gave the client. Everything updated correctly, so it's not choking on the file itself)

My immediate goal is to get this client back in sync, preferrably without any uninstalling and with one unified installer instead of creating a special updater just for them. Since the files are already in the wild if that's not doable I can stomach a special case. My future goal is to make this just work naturally like I assumed it would--file is older version, file gets replaced, nothing else matters.

I think I've provided everything pertinent but if not I can provide more information. I've spent the better part of today looking at this and I simply can't find any material similar to this scenario.

Answer 1

From your description of the scenario, its sounds like the 'modified date' of the key file for the component you patched for your customer could be later than the date in the upgrade package, but the versions are the same. Windows Installer may not be replacing the file. See Replacing Existing Files and the example in the row for FileF

This customer may need to use a custom package that uninstalls the patched component before applying the latest upgrade.