What to do if you have captured lower version of dll and the repackager treated them as Merge Module/Redist
Hello, All.
I have an application that has alot of lower version of dll than machine build (Win7-64B).
After building the .irp file of captured application using repackager, it adds the merge module/redist in the package.
We have same DLLs in the machine what should be the best practice for this scenario on Merge Module?
Thanks!
-
Are you saying that you WANT the lower version files? If so - and I can't imagine why you would! - use isolation. Google for 'Windows Installer component isolation'. - anonymous_9363 10 years ago
Answers (1)
Either use or dont use mergemodules.
It does not make sense that you have captured lower versions. If the packaging machines have newer versions, the old ones should not be installed. There is a setting in InstallShield >tools>Options. On the MergeModule tab, there are tick boxes:
Matching files must have the same version
Matching files must have the same destination
MergeModules aside, the native MSI file versioning rules will apply, meaning, if you capture v1.0 of a DLL and the target OS has v2.0 of the DLL the v1.0 file will not be copied down.
The next trick is to figure out which files are 'flat' and which ones have to be registered for COM info.
If you are capturing flat files, and they are in the application installdir (NOT Windows or System32 or a shared location... CommonFiles) then leave them as files and not use MergeModules.
Personally, I do not use mergemodules. If you use them and then a newer version of a file comes out, do you update all your mergemodules and then all the MSI's that have the older version??
No, why?
Because MSI files versioning rules will save your bacon.
The issue you might have (but its rare) is if your app is hardcoded to use a named specific version of a file, or if the later version of the file (that will end up being used) does not support older functions (I have seen that about 3 or 4 times)
