Using InstallShield 2013 in a Basic MSI project. We have some ancient Microsoft COM DLLs that are shipped in merge modules which we include in our MSI. We now need to update a few of these DLLs with newer ones in a minor upgrade patch (MSP). We don't have new merge modules from Microsoft so I'm trying to figure out how to get these new DLLs installed in our application.
I've added 2 new components, one for each file, and built the new MSP. The files get installed properly, though I did have to register them manually in a custom action, otherwise the patch would be uninstallable (b/c I changed the Class table). This is all good - so far. However, when I remove the patch, these 2 new files are deleted!! This is the problem. I would be OK with them being put back to the previous version - but no. They're straight up deleted. I marked the files as Permanent - same problem. I nulled out the GUID for these two new files - same problem. I would be OK with them being left at the new version since they're MS files. I suspect it's not keeping these around because I'm only marking it permanent in the patch, not in the original MSI. Right?
Here's some MSI log info during the installation of the MSP:
MSI (s) (FC:C4) [16:53:38:949]: File = comctl32.ocx: Final State = Install
MSI (s) (FC:C4) [16:53:38:949]: File = osl.dll1.BD822168_4484_412B_AA08_455F82BE5E0F: Final State = Install
MSI (s) (FC:C4) [16:53:48:371]: SELMGR: Component 'comctl32.ocx' is a new component added to feature 'WDCoreComp'
MSI (s) (FC:C4) [16:53:49:371]: Component: comctl32.ocx; Installed: Absent; Request: Local; Action: Local; Client State: Unknown
MSI (s) (FC:C4) [16:53:53:199]: Baseline: Existing comctl32.ocx version 6.0.81.5 does not match any baseline. Will not be cached.
Here's MSI log info from the uninstall of this MSP:
MSI (s) (FC:B8) [16:57:33:236]: File = comctl32.ocx: Final State = Remove
MSI (s) (FC:B8) [16:57:33:236]: File = osl.dll1.BD822168_4484_412B_AA08_455F82BE5E0F: Final State = Overwrite
MSI (s) (FC:B8) [16:58:01:939]: Executing op: FileRemove(,FileName=C:\Windows\SysWOW64\comctl32.ocx,,ComponentId={100B5DC4-FD2D-4311-9ADE-2B65B814F446})
I included the osl.dll in there to indicate a normal patching routine for one of our DLLs where it's overwriting it with the old version, but it's removing the comctl32.ocx.
Other options seem VERY undesirable:
- use Orca to hack the new bins into the old merge modules and rebuild the installer. Hopefully the patch would recognize that they're new and install them properly
- do this all manually in custom actions: during install save a copy of these files then install the new ones. During uninstall, restore the old versions from our saved copies
- install the files in a temp folder, copy them to the official MS location, then register them there. Uninstall would only remove them from the temp folder and not the official MS location
Number 3 sounds least objectionable but still bad form to do all this manually in custom actions.
