Crystal report in ASP.NET 2.0 - Load report failed error

[mtessier]

Hello All,

We’ve just implemented a solution where ASP.NET 2.0 is opening a Crystal report. We’ve done this successfully in the past, so we thought that we’ve set everything up properly. This has been working well in our Dev and Test environments for quite some time, but the promotion to Production has been a problem. Our first problem was the implementation team missed the installation of the Crystal 2008 runtime (different web server than our previous implementations). This was installed after the fact on implementation day and ever since, we have been getting a “Load report failed” error. The Crystal report was developed in Crystal 9 designer, but has since been converted to Crystal 2008 to see if it resolves the error, but no luck. Tracing the error revealed that this error was triggered by the call to the ReportDocument.Load(reportPhysicalPath) method, the very first method that the web page calls that touches Crystal. My next step was to investigate which Crystal DLLs were installed. We have determined that Dev, Test, and Production have the same versions installed, although most of these DLLs have a 12.0.11 version and a 12.0.2 version living side by side in the GAC. Next, I used the Modules.exe utility to determine which version of each DLL the web page is using when it loads. This is where we found a discrepancy. Dev and Test are loading CrystalDecisions.Shared version 12.0.2, but Production is loading version 12.0.11. What is really strange about this problem is that in our web.config, we are specifying that the web pages should use version 12.0.2 as follows:

<assemblies>
	<add assembly="CrystalDecisions.CrystalReports.Engine, Version=12.0.1100.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.Enterprise.Framework, Version=12.0.1100.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.ReportAppServer.ClientDoc, Version=12.0.1100.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.Shared, Version=12.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.Enterprise.InfoStore, Version=12.0.1100.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.Web, Version=12.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
        <add assembly="CrystalDecisions.ReportSource, Version=12.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304"/>
</assemblies>

The above references were automatically added to the web.config two years ago after we upgraded our Crystal runtime from 2005 to 2008. The Modules.exe utility also revealed that there were some Crystal DLLs that didn’t load in Production, but we’re suspecting that it is because the web page crashed before they got a chance to load. One other difference on the Production server is that Crystal 9 designer is installed, as we make it available as a web-enabled application on our Intranet home page. This has been installed there for years and removing it at this time is not an option.

Can anyone shed some light on this strange problem? I’ve read that this could happen if there is a reference to the old version somewhere before we reference the new version, but this is a brand new install of the runtimes so no other application would be using these DLLs. Unfortunately as a developer I’m locked out of the Production server so anything that I need to do or look at on the server means that I have to go through someone else.

Thanks in advance,

Mike

 

[mtessier]

Hello again,

New information after looking closer at the Modules.exe logs. I looked at the Test and Production logs side-by-side instead of using the "Differences..." feature, and it turns out that both versions of CrystalDecisions.Shared get loaded from both servers. I don't understand why the "Differences..." feature would show that as a difference, but now the problem appears to be that the ReportDocument.Load(reportPhysicalPath) method is failing and we need to find out why.

There are still quite a few crystal-related DLLs that are not loading in Production, but again I would suspect that it is because the web app is crashing before it gets the chance to load.

BTW The report file name has spaces in it, but I'm passing it to ReportDocument.Load() in a variable so I would think that spaces wouldn't be an issue. Anybody ever had an issue with spaces in the report file name?

Thanks,

Mike

 

[mtessier]

More new information. I've setup additional tracing and the inner exception is "Invalid file name". I tried renaming the report without spaces in the filename, and no luck. I've also looked in the c:\windows\temp folder and the temp files are being created and left there. We have coded the web page to clean up the resources when done and the tracing is showing that this cleanup code is being executed even though an exception is being thrown. Looks like the process is getting stuck sometime after the temp file is written to c:\windows\temp. We have setup IIS_WPG with read/write permissions on this folder (our app pool is setup to run as IUSR_[machinename]).

Thanks,

Mike

 

[mtessier]

Problem solved. Since this web application uses Windows authentication, the appropriate Windows user accounts (or groups) need Write permission to the C:\Windows\Temp folder in addition to the permissions that were setup for IIS_WPG.

Thanks,

Mike