Re: Best way to handle creating Merge Modules for 3rd Party software
I had no other issues with these merge modules. You do need (sequence numbers are MS
<SelfRegModules Sequence="5600" />
<SelfUnregModules Sequence="2200" />
<ScheduleReboot Sequence="6410" />
It requires reboot to function properly.
I used that with an older version of WiX. Have not tried to rebuild it wit latest.
Typically you need just two MSMs:
<Merge Id="MRG_CRRTIME" Language="1033" DiskId="1" src="Binary\CrystalReports11_RDC_Runtime.msm" />
<Merge Id="MRG_CRENGNE" Language="1033" DiskId="1" src="Binary\CrystalReports11_RDC_Reportengine.msm" />
And then use MergeRef in the feature(s).
Since some of the components install into common locations you have to be careful. If you
dont have ALLUSERS set, current user may not have write permission to one of these
locations. There are plenty of properties in merge modules, including component/file
selections and paths, that you can set in your wrapper. Dark the MSMs and you'll see what
they are and what they do. I chickened out by using ALLUSERS=1. I can do that in my
Thursday, September 15, 2005, 7:44:07 PM, you wrote:
> With 8.5 you may be better off authoring a fragment/include and using that
> in all your WiX setups. Atleast that is the approach we took here. This also
> allows you to follow Windows Installer best practices like "SelfReg is Evil
> - avoid at all costs". You could also go all the way and author a Merge
> Personally I have not been overly impressed with Business Objects' Merge
> Modules (as Alexei points out they require SelfReg turned on!). In XI they
> mandate the use of Merge Modules but I have had trouble using WiX to wrap
> them (any help you can provide Alexei?) - ended up using InstallShield!
> -----Original Message-----
> From: Alexei Boukirev [mailto:[hidden email]]
> Sent: Friday, 16 September 2005 7:43 AM
> To: [hidden email] > Subject: Re: [WiX-users] Best way to handle creating Merge Modules for
> 3rd Party software
> Hello Jon,
> indeed, BusinessObjects never released MSMs for Crystal Reports 8.5.
> There is a tech
> document with the Developer version of the application that tells you
> which files/DLLs
> should be installed and to which directories under certain conditions.
> Then it's up to
> you to either create MSM or just code in things into your MSI. That's what
> I did. Apply
> SP3 on your development computer and then get those updated files while
> authoring your
> Now I am on Crystal Reports XI (11) and they (BusinessObjects do release
> merge modules for
> that product, updated and available from them to registered users).
> That run-time is
> compatible with older versions of reports. But if your customer decided to
> install report
> authoring application on computer with latest run-time it better be
> latest version of
> Crystal Reports. Also, Crystal Reports 11 MSMs REQUIRE SelfReg turned on.
> Thursday, September 15, 2005, 4:26:41 PM, you wrote:
>> I'm stuck in a situation and I wanted to know how you recommend handling
>> this. I have an application that uses Crystal Reports 8.5 SP3. I need
>> to distribute the said application and the problem I have is that no one
>> (read: Crystal Reports, Installshield, Microsoft, or any other company
>> that I can see) released a set of Merge Modules for SP3. I have created
>> my own Merge Module for CR85SP3 and have included this in the past when
>> trying to redistribute our application.
>> I know creating Merge Modules for 3rd party applications is greatly
>> frowned upon but I'm not really sure what other options I have available
>> to me except to change the existing application to only use an older
>> version of Crystal Reports (which doesn't sound like a good idea to
>> me). Conversely I don't think I can upgrade the application to use the
>> latest version of Crystal Reports which is now on version 11.
>> Any thoughts? Should I continue in my ways by using my own custom merge
>> module or is there some other method that would be good to take?