Crystal Report Application Sharing Issue

Question

We are receiving the following error message when trying to open up Crystal Reports from within our application.
Unable to load Crystal Report user function dll:
   e:\Program Files\Centricity Practice Solution 90\Client\mlcrwlib2.dll.
The report may not run correctly.
Here is an explanation of our current environment:
We are utilizing Crystal Reports XI R2 SP6 using the ActiveX Designer control, craxddrt.dll, to open up Crystal Reports within a  Visual Basic project.  I did not see a VB forum so I'm posting here in .NET.
We are including the 4 Crystal Merge Modules in our InstallShield Project when installing our application so we feel we are installing correctly, but there appears to be a Crystal Reports sharing issue with another application.  When we attempt to open up our Crystal Reports from within the application, we get the error message above.  If we click OK to the error message our report opens.  I would like to eliminate the error message, but I'm not sure why we are even calling the file in the error above.
I'm assuming that the other application has created a user function or something that is registered within Crystal Reports, but we do not have access to or cannot load it.   We have not been able to reach anyone from the other software application company to ask questions so I'm hoping that someone can point me in the right direction as to what is going on here.
I have verified that the Business Objects folder was created with the run-time files needed to run Crystal Reports.  I also see a previous version of Crystal Reports run-time files on this server since a Crystal Report folder exists.  I have utilized Process Monitor to see that the correct craxddrt.dll is being opened, but I cannot figure out how the file in the error message above is being called.
Any help on this issue would be greatly appreciated.

Answer 1

Hello Marlon,
I worked on a Centricity (GE Medical) issue with the Report Designer Component (RDC) a number of months ago. As part of my troubleshooting I discovered that their application uses an atypical deployment of the Crystal runtime files for their Centricity application. The "short" version is that the way they implemented the RDC would not have been supported by SAP Support.
I was never able to resolve the Centricity issue, but proved that their implementation of the RDC was the root cause of the issue. The mlcrwlib2.dll is a Centricity DLL that seems to control how/where the craxdrt.dll / craxddrt.dll file is loaded (location A in one work stream in their application, location B in another work stream in their application).
One of the side effects of this DLL is that it "took over" how the craxdrt.dll would load for any other application that also used the RDC (craxdrt.dll / craxddrt.dll). I proved the issue by sending them a simple sample application that was written in CPP. Using CPP allowed us to eliminate the need to reference any other dependencies besides the Crystal runtime files. This sample application consistently failed with a reference to their mlcrwlib2.dll - which I knew wasn't referenced in my CPP sample. At the time Centricity wasn't able to explain why their mlcrwlib2.dll was being picked up by my sample. I expect that their issue would be resolved once they discovered why mlcrwlib2.dll loaded erroneously, but they were still working on the answer to that question.
Because we couldn't determine how and why the mlcrwlib2.dll was behaving as it did I'd suggest not trying to use a "side by side" installation of another RDC application. I know it's not much of an answer, but it might help explain why all the regular troubleshooting steps aren't working for you.
Sincerely,
Dan Kelleher