Video Screencast Help

32 bit merge module not installing on 64bit os

Created: 19 Jul 2013 • Updated: 25 Jul 2013 | 4 comments
This issue has been solved. See solution.

I'm running wise installation express 7.0 and i have a wsi project that correctly creates an installer for 32 bit systems. At the moment it can also install correctly on a 64bit system and run without hiccups (running on 32bit). 

One of the components in this installer is an IE plugin; I need to be able to install a 64bit version of it so that it can also run on a 64bit browser. Most of it is .net which is compiled with a "Any cpu" configuration which works fine, and their are also some c++ dlls which i managed to get working by adding a 64bit condition on one of the features which installs the 64bit equiavlent dlls. 

So far so good, but I am running into a problem. The project has a merge module that installs the 32bit version of  crystal reports 2005. The project creates an installer but during intallation shows the error: 

Error 1904, Module c:\programfiles (x86)\Common Files\Business Objects\2.7\bin\crqe.dll failed to register 

for most of/all the crystal report dlls. 

I'm thinking that the installer is trying to register these dlls as a 64bit dll rather than 32. 

Is my assumption correct? and is there a way to force the module to install as 32? 

Operating Systems:

Comments 4 CommentsJump to latest comment

EdT's picture

An MSI can be either 32 bit or 64 bit as detailed in the summary information stream. When you try to target both 32 bit apps components and 64 bit app components in a single MSI then you start to run into problems.

As a test, put the merge module for crystal reports into a 32 bit MSI separate to the rest of the project and see if it will install then. 

As a separate question, does the crystal reports merge module rely on the SelfReg table to register the DLLs?  If so, you need to be aware that self registration is not recommended by Microsoft for reasons well documented in MSI.CHM. You may have better success if you extract the registration information from each DLL and then install it using the correct registry table family and avoid selfreg entirely.  Or just don't use selfreg and call regsvr32.exe after the install to register the various DLLs.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

VBScab's picture

>call regsvr32.exe after the install to register the various DLLs

"Burn 'im! Burrrrrrrrrn 'im!" :-)

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using before posting.

EdT's picture

Hi Scabbers

OK, WiseComCapture might also be an option depending on the skill level of the packager.

Burning - yup, it's pretty hot here...<g>

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

marcomuscat's picture

The problem was not in the installer; I was missing the 64bit version of the c++ rruntime which is required by crystal reports. 

placing the msm in an empty project helped me isolate the problem.