Merge modules are generally now considered bad practice - they become impossible to service, because the module does not retain its identity. The only way to service them is to patch the products which have merged the module. Crystal Reports had a security patch earlier this year: http://www.microsoft.com/technet/security/Bulletin/MS07-052.mspx.
I would go with merge modules only where that's the only ship vehicle available or where the technology used supports some form of publisher redirect so that a new version issued by the publisher can supersede the broken version, for example .NET assemblies in the GAC or Win32 assemblies, using publisher policy (although detecting that the update is required is still problematic). WiX schedules only those standard actions which are necessary to install your package. It does so by checking which tables have actually been used. This is to save space in the package and time when installing. This can sometimes cause problems if the merge module does not schedule an action which it relies on, where the MSI does not require that action. At a guess - as I refuse to have Crystal taint my system - I'd say that the merge module makes use of the Class table, etc. (0x80040154 is REGDB_E_CLASSNOTREG, 'Class not registered'.) That means that the RegisterClassInfo and UnregisterClassInfo actions should be scheduled. You can either do this explicitly by adding those actions to the InstallExecuteSequence, or ask WiX to include the Class table by using an EnsureTable element, which in turn will cause it to include the appropriate actions. You may also find that it requires type libraries to be registered, in which case you need the RegisterTypeLibraries action or to force the TypeLib table to be included. There is also a ProgId table that might be necessary. If it's really badly written there might be a SelfReg table as well. You might well have to crack open the merge module with a tool such as Orca to find out what's really required. This problem does not occur with VS or with InstallShield because they simply dump the entire suggested InstallExecuteSequence (http://msdn2.microsoft.com/en-us/library/aa372038.aspx) into the MSI, regardless of whether the actions are needed or not. -- Mike Dimmick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 30 December 2007 00:45 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crystal Reports Merge Module Installation Woes I am using Wix v3 Build 3.0.3632.0 and am trying to merge the Crystal Reprots for Visual Studio 2005 merge module into my project. I can not get the reports to work on the installation box. I created identital setups using InstallShield 9.0 and the Visual Studio 2005 setup projects. BOTH OF THESE WORKS. THE PROJECT BUILD WITH WIX FAILS. The project is real simple (designed just the troubleshoot this problem), one .NET 2.0 exe displaying an embedded report. When I launch the exe from the Wix 3.0 install, I get the error: type initializer for 'CrystalDecisions.CrystalReports.Engine.ReportDocument' threw an exception. ---> System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {11BD5260-15B6-412D-80DB-12BB60B8FE50} failed due to the following error: 80040154. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
