I have a question concerning the way Merge Module redistributables are referred in the Installshield msi projects
Short: Is there any way to always refer to the latest version of a Merge Module for a msi project? (referred by filename only - no GUID's)
Detailed: The Merge Modules are identified by a filename and an unique GUID, making sure that it is the correct module we are referencing. As an example, imagine we have included the Merge Module Visual C++ 10.0 CRT (x86), and are therefore having a reference to Microsoft_VC100_CRT_x86.AFA96EB4_FA9F_335C_A7CB_36079407553D. The filename is Microsoft_VC100_CRT_x86.msm and the GUID is {AFA96EB4-FA9F-335C-A7CB-36079407553D}. On our machines this Merge Module is located both in ...\InstallShield\2012\Modules\i386\Microsoft_VC100_CRT_x86.msm ...\CommonFiles\Merge Modules\Microsoft_VC100_CRT_x86.msm
The Module is the redistributable runtime to the compiler, so the runtime version shall match the code produced by a given compiler version. Therefore we prefer to use the ..\CommonFiles\Merge Modules location as it is updated each time the compiler i.e. VS 2010 is updated.
The problem is that each time the Merge Modules is updated we can no longer build until we have to updated all the msi projects that referrer to that Module. Is there a way to remove this binding from the msi projects ? Ex. by having a masked reference like Microsoft_VC100_CRT_x86.*
Why not include the VC++ 10 Prereq instead of the MSM? Can someone explain the difference between the 2? I know using an MSM embeds all the VC++ components into your msi - the prereq does not, just installs it outside of installer. And doesn't Windows Update the VC++ Runtimes? At least that's what I got from my developers.
