This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Merge Module Management in IS
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 20, 2011
06:43 AM
Merge Module Management in IS
Dear Flexera.
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.*
Looking forward to hear from you!
Best regards
Christian Schmidt
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.*
Looking forward to hear from you!
Best regards
Christian Schmidt
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Dec 21, 2011
08:52 AM
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.
Regards,
Tom
Regards,
Tom