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
- :
- Re: Problems with Standalone Build Helper and merge modules
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
‎Feb 12, 2013
10:02 AM
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:
...
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?
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:
Microsoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED2 | 0 | Visual C++ 10.0 MFC (x86) |
...
Main | Microsoft_VC100_MFC_x86.1DEE2A86_2F57_3629_8107_A71DBB4DBED2 | 0 |
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?
(5) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 12, 2013
10:29 AM
Did you verify the correct signature in the ModuleSignature table inside the merge module? You might have some form of DLL/MSM hell.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2013
03:39 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2013
07:10 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2013
10:06 AM
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2013
10:25 AM
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 ).
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 ).