How to redistribute Crystal Reports for VS2005 to Vista?

Question

I have a WinForms app built using Visual Studio 2005, including the crystal reports that comes with VS2005 to run and view reports. My installer uses the merge module CrystalDecisionsRedist2005_x86 to install Crystal. This all works well until I try installing on Vista, when I get errors registering the Crystal dlls. It seems this is a well-known problem, as reported in forums such as here, here and here, but as with these things there's no generally accepted solution that I can find, and business objects moving their sites around doesn't help either. (A perfect example of a problem where stackoverflow is needed).

So how do you deploy Crystal Reports for VS2005 apps to Vista?

MORE INFORMATION:

The Vista errors logged to event log come in pairs like this:

Activation context generation failed for "C:\Program Files\Common Files\Business Objects\2.7\bin\ExportModeller.dll" Dependent Assembly Microsoft.VC80.ATL,processorArchictecture="x86".... could not be found. Please use sxstrace.exe for detailed diagnosis.

then

Product: Error 1904. Module "C:\Program Files\Common Files\Business Objects\2.7\bin\ExportModeller.dll" failed to register. HRESULT -217010895. Contact your support personnel.

and so on for various other dlls.

My installer includes the merge modules for ATL, but I guess they're not getting applied first. There's no way in my Wise Installer Edition to specify which merge modules are applied first.

I've tried installing the Crystal Reports X1 merge module instead, in the vain hope that it would be backwards compatible with 10. But while the install works fine I get an exception when I try to run a report, with a reference error because it can't find the appropriate assembly. Not too surprising.

I've also tried using the CrystalReports10_NET_EmbeddedReporting.msm merge module available from the Business Objects support Software Downloads site (file is titled 'Merge Modules for CR 10 .NET Deployments -En')

I'll continue on my list of things to try from various threads, but would love it if someone had 'the answer'.

thanks.

CURRENT SOLUTION

My current method/workaround is to install the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) on the Vista machine before installing my MSI. That allows my normal MSI to work fine on Vista, but isn't ideal as I only want to distribute a single exe.

I've also raised this on the SAP/CrystalReports forums here.

EVEN MORE INFO

The release notes for CR for .NET SP1 note that this problem existed and is now resolved:

ADAPT00738607

Description: When installing a customized Setup project with the Crystal Reports for Visual Studio 2005 merge modules (.msm) on Vista, several COM components fail to register. e.g. "Module C:\Program Files\Common Files\Business Objects\2.7\bin\ExportModeller.dll failed to register. HRESULT -2147010895. Contact your support personnel." If you run the setup.exe again and select repair, the installation will go on without any error, and the component can be registered.

New Behavior: This problem is resolved

However, I still haven't found any updated merge modules, so I'm not clear where this problem has been resolved. Their suggested workaround, to repair the installation, is worth considering if you don't want to have to install the C++ package separately.

Answer 1

I ran into this problem today. It seems like there should be an easier way to have an msi file install its prerequisites.

Googling gives the following blog that explains the problem. It lists the following solutions:

1. Install the VC 8.0 runtimes using the redistributable package via a setup chainer
2. Install private copies of the VC 8.0 runtime files.
3. Statically link to the VC 8.0 runtimes when building your binaries so that they will not depend on the global assemblies
4. Use a commit custom action or a custom action scheduled after InstallFinalize.
5. Convert the self-registration information to standard MSI authoring and stop using self-registration.

I couldn't use option 1, because I wanted a single MSI file.
I couldn't use options 3 or 5, since it's a third party lib.
I didn't want to use option 2, since I didn't want to deal with private copies of the files.

This left option 4. This doesn't seem to be the best way, but it worked for me. I edited the CrystalDecisionsRedist2005_x86 merge module (using InstallShield) and removed the entries in the SelfReg table. I then created a custom action scheduled on Commit to register the files that I removed.