Most versions of Crystal Reports from CR 9.1 have shipped runtimes for .NET in an MSM and MSI format. In this blog, I'd like to discuss each option; the why, the when and also the future.
Previous to Crystal Reports 9.1, only CR 8.5 had MSM file(s) - if you used the Wise Deployment Software. I don't remember the version of Wise, but the MSM file(s) was there (I don't even remember if it was one MSM file or more than one. And I am pretty sure the MSM would only apply to the Crystal Reports Report Designer Component (RDC) anyhow. And since the RDC is not supported in .NET, let's move on.
Crystal Reports 9.1 (bundled with .NET 2002 and 2003) shipped only MSM files. For .NET 2002 these were; Database_Access.msm, Database_Access_ENU.msm, Managed.MSM, RegWiz.msm. For .NET 2003 the files were; Crystal_Database_Access2003.msm Crystal_Database_Access2003_enu.msm Crystal_Manged2003.MSM Crystal_Regwiz2003.msm. There was no MSI file. But compiling the MSM files into an MSI is a trivial process.
Crystal Reports 10.2 (bundled with .NET 2005) shipped only MSI files; CRRedist2005_IA64.msi (64 bit Itanium), CRRedist2005_X64.msi (64 bit Intel), CRRedist2005_x86.msi (BootStrapper). MSM files were provided at a later time as a download: https://smpdl.sap-ag.de/~sapidp/012002523100005853292008E/cr_net_2005_mm_mlb_x86.zip
Crystal Reports 10.5 (bundles with .NET 2008) shipped only MSI files; CRRedist2008_x86.msi, CRRedist2008_x64.msi, CRRedist2008_ia64.msi. MSM files were never provided.
All other versions of Crystal Reports shipped both MSI and MSM files.
Looking at the above you may detect a certain pattern. And the pattern will continue with CRVS2010 and CR2011 (or what ever it will be called); no MSM files. Period. I suspect initially (at least that is how I explained things to my self) the MSI was a great no nonsense runtime deployment to a server environment. Double click and voila, runtime is installed. No pretty interface, no other runtime to bother with. And MSM files were great for nice looking customized setup packages (setup.exe).
Unfortunately, using the merge modules has been getting more and more problematic over the years. For Crystal Reports, this all started back after Service Pack 1 for CR 2008 when we had to pull the Visual C++ library files out of our merge module package. This was due to licensing issues. E.g.; Microsoft does not allow you to add their runtime to MSM files (if you can find the VC++ runtime - but that is another story).
If you can bear it, we recommend to always use the redist MSI or EXE package that we provide because it has everything you need in one package. We actually recommend to use the MSI files for .NET Windows Form based solutions along with the web based ones. When creating an MSI file, we are permitted to include our merge modules in that setup, plus the Microsoft Visual C++ libraries we need to allow our software to work. In this way, if the VC++ dependencies change (as they often tend to do), all you need to do is update the reference to the CR MSI and not hunt all over the Web for new Microsoft dependencies.
Another reason why we recommend to use the MSI or EXE redist package is that it segregates the Crystal Reports .NET runtime from your application. When there is an update to the CR .NET runtime, and let's be honest there will be an update, you can simply go into Add/Remove Programs or Programs and Features and remove the Crystal Reports .NET runtime. Then install the new one. This is done without completely removing your application.
When you use the merge modules you have effectively bound the Crystal Runtime to your application. You'll need to re-package your entire application in order to update the CR .NET runtime in the event there is a patch you need for Crystal. This will mean uninstalling your application as well. Your application could have many config files, databases, or other components that require some detailed configurations to work well for your client.
Note that Crystal Reports Service Packs and Fix Packs can not be installed to runtime computers. These can only be installed on the computer that has the Crystal Reports Designer installed. Thus if you can, use the redist MSI or EXE that we provide and don't use the merge modules. They are getting tougher and tougher to use; bye, bye MSM files...
One last thing; an acknowledgement to David Hilton who has done an insane amount of work on these issues. The KB below and others are his handiwork. And even a significant portion of this blog is based on his answer to one of the forum threads on the .NET - SAP Crystal Reports () forum. Thank you David for keeping me sane.
Additional resources
Building a deployment project with Crystal Reports 2008 (.NET 2005 & .NET 2008)
The specified item was not found.
KB #1495319 - Error: Module failed to register CEReportSource. installing Visual Studio .NET applica...
Business Objects Support Software Downloads web page
KBase search page
