Crystal Reports Spacing different between WPF and Web Service

[Former Member]

Hi,

We export a Crystal Report to PDF via two different applications. One is a WPF application and the other is a WebApi Web Service. Both use the same CrystalDecision dlls (shown below).

The problem is that there are minor discrepancies in character spacing between the two. Shown below:

wpf-vs-webservice.png

We've confirmed that WPF is the determining factor. We did this by creating a dummy WPF application and hardcoding the same report files and datasets that were being used on the Web Service and exporting. The same discrepancies appeared. This did not happen when we ran the same experiment on WinForms or as a Console Application.

Our question is, how do we get the WebService to export the reports the same way a WPF application would? As we understand it, WPF does some special initialization on startup that points Crystal Reports to particular graphic APIs (GDIPlus or libpng10...). Is there a way to achieve the same effect on a web server?

Thank you for your time.

WPF Application .NET version: 3.5

Web Service .NET version: 4.6.1

CrystalDecisions.CrystalReports.Engine.dll version: 13.0.10.1385

[Former Member · Accepted solution]

Managed to figure this out and posting here in case anyone has the same issues:

The SP update did in fact fix the problem locally but there was an extra step we had to perform after updating our Dev Servers.

We had to make sure that the "Load User Profile" setting in IIS was set to true since there were certain .dll paths that required read permissions (Not exactly sure which ones).

[former_member11696]

Hi Dang,

Changing Tag to CR for VS.

You are using SP 10, SP 20 was just released. Try it and see if that fixes it, lots of updates since SP 10 for the WPF viewer.

https://wiki.scn.sap.com/wiki/display/BOBJ/Crystal+Reports%2C+Developer+for+Visual+Studio+Downloads

Don

[Former Member]

Hi Don,

We updated to SP 20 and everything seemed to work fine locally, but after installing the .msi for the runtime (not the .exe install) on our webservers that host the webservice, we saw the same problems.

Also, this may not have anything to do with the problem, but we were not able to run the application without installing BOTH the 32-bit and 64-bit runtimes on the same box.

[former_member11696]

I've been on holidays...

Since SP 20 resolved the issue on your DEV PC then run ProcessMonitor or Modules and compare runtime and permissions. Make sure it's using the updated runtime and not SP 10.

Not sure why you need both platform MSI's, could be some dependency you are using that may only support 32 bit API's.

Don