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:
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
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:
Code:
<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