cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
awelzel
Level 3

Problems with Standalone Build Helper and merge modules

In the past we already used InstallShield 2011 and the Standalone Build Helper on our build machine (Server 2008 R2) without problems.

Now we tried to migrate to InstallShield 2012 Spring Premier. The 2012 Standalone Build Helper does not find any merge module What i did:

1) Copied all merge module from the development machine (C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386) to the build server.

2) Used the Option "-o" to specify the path where the modules are.

3) Since "-o" did not work, also tried to specifiy the path using the registry key HKLM\SOFTWARE\Wow6432Node\InstallShield\19.0\Professional\MMSearchPath

The error is always the same:

ISDEV : error -4075: File not found. An error occurred merging Module 'Microsoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED2:0' for Feature 'Main'.
ISDEV : fatal error -5087: Stop at first error
Default\Default - 2 error(s), 1 warning(s)

It does not matter, which module i try - it did not work with ANY module.

Then we set up a completely new machine to make sure, there is no problem with the existing server - no change. IsCmdBld does not find the merge modules.

On the development machine using the InstallShield IDE everything works fine. And the modules are reference in the project in the following way:


ISMergeModule
Language
Name
Destination
ISAttributes

Microsoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED20Visual C++ 10.0 MFC (x86)

...

Feature_
ISMergeModule_
Language_

MainMicrosoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED20


And yes - the file Microsoft_VC100_MFC_x86.msm exists in the path, which i specified using "-o" or the registry key as described above.


Any idea?
Labels (1)
0 Kudos
(5) Replies
Christopher_Pai
Level 16

Did you verify the correct signature in the ModuleSignature table inside the merge module? You might have some form of DLL/MSM hell.
0 Kudos
awelzel
Level 3

Christopher Painter wrote:
Did you verify the correct signature in the ModuleSignature table inside the merge module? You might have some form of DLL/MSM hell.


The merge modules are identical to the ones which work fine on the development machine, since i just copied the modules from there and then told SAB with the "-o" option the path.
0 Kudos
Christopher_Pai
Level 16

Sorry, I'm drawing a blank. I make extensive use of merge modules ( say 1000 modules going into a given installer ) and I've never seen this problem in any version of InstallShield using the SAB. I've used both the IsCmdBld -o and the InstallShield MSBuild Targets file and both work fine.
0 Kudos
awelzel
Level 3

Christopher Painter wrote:
Sorry, I'm drawing a blank. I make extensive use of merge modules ( say 1000 modules going into a given installer ) and I've never seen this problem in any version of InstallShield using the SAB. I've used both the IsCmdBld -o and the InstallShield MSBuild Targets file and both work fine.


Ok - i think, i found the problem - but is still very confusing:

1) When i select the redistributable "Visual C++ 10.0 MFC (x86)" in the list of available merge modules within the InstallShield Authoring Tool the project gets a reference to the signature "Microsoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED2"

2) When i then check the ModuleSignature table of "C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386\Microsoft_VC100_MFC_x86.msm" (this is the path which i used to copy the modules to the build server, where the SAB is installed) i see that the signature is in fact "Microsoft_VC100_MFC_x86.AFA96EB4_FA9F_335C_A7CB_36079407553D" and NOT the one, which was added by the Authoring Tool.

So - where does the wrong signature come from? After some more investigation i found the problem:

InstallShield 2012 Spring Premier seems installs TWO versions of the Merge Modules:

C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386
C:\Program Files (x86)\Common Files\Merge Modules

In fact the Authoring Tool uses the SECOND path to build the list of available modules although the module search path is

C:\InstallShield 2012 Spring Projects\MergeModules,C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386,C:\Program Files (x86)\InstallShield\2012Spring\Objects,C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386\Japanese,C:\Program Files (x86)\InstallShield\2012Spring\Modules\i386\German,C:\Program Files (x86)\Common Files\Merge Modules

At least this is really confusing - why two sets of nearly identical merge modules? Which one is the one to use - since there are different signatures i assume one of them is a newer version?
0 Kudos
Christopher_Pai
Level 16

Like I said previously, verify the signature matches and rule out MSM hell.

There is a long history of various modules posted by different people and some of them are not without problems. Personally, I don't automatically use merge modules just because someone (Flexera) put them on my dev machine. I maintain a repository of vetted merge modules and keep them in source control. During the build I copy them into scope and/or set the msm search path to include the directory.

This gives me very tight CM control and reliable builds ( builds on any machine ).
0 Kudos