CRforVS_13_0_12 not working with 64-bit application

[former_member1024740]

I am in the process of migrating 32-bit application to 64-bit.  To make the current Crystal Reports component working with 64-bit, I did the following:

1) Ran the Install Executable of CRforVS_13_0_12 and selected 64-bit at the end of the installation

2) Referenced the required assemblies to the newly installed version 13.0.12.1494 located in “…\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\” directory (note that this is weird that nothing can be found under the “win64_x64” folder)

3) Compiled my application in x64 platform (succeeded)

4) Set “Enable 32-Bit Applications” to false for the Application Pools in IIS

5) Running application in 64-bit mode looked fine until I ran the Crystal Report. Exception was thrown during Export():

*********************************************

Exception Type: System.Runtime.InteropServices.COMException

ErrorCode: -2147467259

Message: The system cannot find the path specified. TargetSite: System.Object Export(CrystalDecisions.ReportAppServer.ReportDefModel.ExportOptions, CrystalDecisions.ReportAppServer.ReportDefModel.RequestContext)

StackTrace Information

*********************************************

   at CrystalDecisions.ReportAppServer.Controllers.ReportSourceClass.Export(ExportOptions pExportOptions, RequestContext pRequestContext)

   at CrystalDecisions.ReportSource.EromReportSourceBase.ExportToStream(ExportRequestContext reqContext)

   at CrystalDecisions.CrystalReports.Engine.FormatEngine.ExportToStream(ExportRequestContext reqContext)

   at CrystalDecisions.CrystalReports.Engine.FormatEngine.Export(ExportRequestContext reqContext)

   at CrystalDecisions.CrystalReports.Engine.ReportDocument.Export(ExportOptions options)

Trouble-shooting that I did: 

1) This new version 13.0.12.1494  only works if I compiled my application in AnyCPU platform with “Enable 32-Bit Applications” set to True.

2) Here is the info from the corflags for the assemblies under the win32_x86 folder (e.g. corflags CrystalDecisions.CrystalReports.Engine.dll), which indicates they are actually 32-bit:

        PE: PE32

        32BITREQ: 0

        32BITPREF: 0

Any ideas of why the exception above was thrown and how this can be resolved?

Many thanks!

[former_member11696 · Accepted solution]

Known issue, we are working on it:

http://scn.sap.com/message/15507162

Trying to get it fixed in SP 13.

Don

[former_member1024740 · Accepted solution]

Thanks for the response, Don.

Just a note that the problem I have here is 64-bit specific, while bitness was not mentioned in the linked issue you provided and the problematic scenario described wasn't exactly the same as mine. 

I'm just hoping that my problem is not overlooked in the coming fix, just in case.

Looking forward to getting the fix!

[former_member11696 · Accepted solution]

Hi Erica,

Possibly not the same issue but I am getting it fixed in both 32 and 64 bit, or at least verified in both.

Can you paste in your code when exporting? I'll test your scenario.

What version of VS are you using?

Thanks

Don

[former_member1024740 · Accepted solution]

I'm using VS2012.

The original code in my application is too much to post here. I'm now showing the flow of how the function is calling which is pretty straight forward:

Dim cr As New ReportDocument

cr.Load(file_name, OpenReportMethod.OpenReportByTempCopy)

' code block to get dataset

cr.Database.Tables(table_name).SetDataSource(ds.Tables(0))

' code block to create ExportOptions

cr.Export(exportOptions)   ---> exception described above was thrown at this line

Thanks,

Erica

[former_member11696 · Accepted solution]

Hi Erica,

This may have something to do with the problem. You stated:

2) Referenced the required assemblies to the newly installed version 13.0.12.1494 located in “…\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\” directory (note that this is weird that nothing can be found under the “win64_x64” folder)

DO NOT browse to the folder. I'm updating VS right now but you should notice when you add .NET Assemblies you should see both 32 and 64 bit, x86 and x64 folders. Make sure you are selecting the x64 versions.

Depending on how and which template project you select depends on if that option is available or not. otherwise just select the usual Engine, Shared and Web Viewer as well as RAS components if you are using then.

NEVER browse to the CR assemblies, it does cause issues later on, always use the list in the add assembly Wizard and .NET tab.

Don

[former_member1024740 · Accepted solution]

Hi Don,

The main issue is that the physical 64-bit assembly files do not exist in the win64_x64 installation folder at all.

All CrystalDecisions assemblies shown in the .NET Assemblies, per your suggestion, are pointing to the win32_x86\dotnet\ folder, no CR assemblies are shown under the win64_x64 folder.

Our application requires to support 32-bit and 64-bit and therefore I have to keep the 64-bit assemblies in a separate folder and make the project file to select the required bitness assemblies conditionally. The way you suggested to adding 64-bit reference to the project does not work for me.

BTW, referring to your suggestion, do you really see the physical assembly files under the win64_x64 installation folder?  If not, how they can be magically shown in the .NET Assemblies?  If you do see them but not for me, did I run the installation incorrectly?

Thanks,
Erica

[former_member1024740 · Accepted solution]

BTW, in case I misunderstood, can you send me a screenshot of what I should see and where, as you stated in the bold typed and underlined below?

DO NOT browse to the folder. I'm updating VS right now but you should notice when you add .NET Assemblies you should see both 32 and 64 bit, x86 and x64 folders. Make sure you are selecting the x64 versions.

[former_member11696 · Accepted solution]

Hi Erica,

No they do not, all are in the GAC which is where VS loads them from in your project.

When adding References you'll see this screen off the properties:

Then this screen if you add references:

But this can change depending on which way you create the WEB project and if in C# or VB. But the steps are the same.

You don't specific select which platform to use, it's all based on the App Pool setting. If your WEB app is 32 bit then X86 MSI, if it's 64 bit then install the X64 bit MSI.

Hope that's clear.

Don

[former_member1024740 · Accepted solution]

Hi Don,

The reference manager in my VS2012 is different from the older version you are in and here is the screenshot of mine that shows the path of those assemblies is from the \win32_x86 folder:

Actually, with this new version, I can get my solution compiled in both x86 and x64 platform without warnings. However, Export() function does not work if the application is running 64-bit mode but ok with 32-bit mode.

As I mentioned earlier, the way that you add references is not applicable to my case.  I will have to check in the physical assembly files as source controlled. We have been doing the same for 32-bit application with the older version referenced without problem.

So the only problem that I need the fix for is:

- run the application in 64-bit mode

- calling cr.Export(exportOptions), as the flow I provided above, returns a report instead of throwing exception

Thanks!

[former_member11696 · Accepted solution]

Hi Erica,

Ah yes, VS 2012 did change the Reference UI, same thing though, don't use the Browse button, must add them from the Extension option by clicking on the check box beside the CR Assembly.

64 bit stuff is in the GAC. Check them in from the GAC.

This is the same issue, SP 13 should have it fixed.

Don

[former_member1024740 · Accepted solution]

Hi Don,

If you pay attention to the screenshot I attached, the path of the assemblies shown in the Extension is actually pointing to win32_x86\dotnet folder.

I gave it a try to copy files from GAC_64 (even though they are under the same win32_x86 folder) and did a beyond compare with the ones physically sitting in the installation win32_x86, they are the same in terms of product version and file size. So I "concluded" that the way how to reference the assemblies would make no difference, at least in my case with VS2012.

Another problem I found is that some assembles I needed do not exist in the GAC_64. They are:

CrystalDecisions.CrystalReports.Design.dll

CrystalDecisions.CrystalReports.Engine.dll

CrystalDecisions.Data.AdoDotNetInterop.dll

Do you mean that SP13 will fix the problem found in the Export() function in 64-bit mode? If so, when should I expect to get it?

Thanks,

Erica

[former_member11696 · Accepted solution]

Hi Erica,

OK time to get back the actual issue. However you added the assemblies doesn't matter, if it work then great...

There appears to be an issue in SP 12 with Export to Stream which was recently discovered and confirmed by R&D.

SP 13 should have the fix...

Don

[former_member183750 · Accepted solution]

Please see the following Discussion for the latest update:

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Follow us on Twitter

[former_member1024740 · Accepted solution]

Hi Ludek,

Just to emphasize that my problem is 64-bit specific, which is different from the linked discussion you provided.  I don't care about exporting to a memory stream.

To summarize:

- with 32-bit crystal report APIs, using ReportDocument.Export(myExportOptions) works fine.

- with 64-bit crystal report APIs, I got the above mentioned exception given when using the same Export() function.

I really need this Export() function to be fixed for 64-bit platform. This disability blocks us from migrating our application to 64-bit.

BTW, calling ReportDocument.ExportToStream() also throws the same exception with 64-bit APIs.

Thanks,

Erica

[former_member1024740 · Accepted solution]

When should I expect to get the SP13 for the fix?

[former_member11696 · Accepted solution]

Hi Erica,

Back on Dec 5, 2014 2:14 PM you added info on your code work flow but you did not show what export options you were selecting/setting.

Can you paste in that part of your code, or even better create a simple test app that replicates the issue using a report with sample saved data?

Zip it all up and rename the zip file to *.txt and then attach.

SP 13 is close, no exact date yet but within the  month likely unless there are some serious ship killers found.

Don

[former_member1024740 · Accepted solution]

Here is the options:

Dim oExportOptions As New ExportOptions

Dim oDiskOptions As New DiskFileDestinationOptions

oDiskOptions.DiskFileName = serverFileName

oExportOptions.ExportDestinationType = ExportDestinationType.DiskFile

oExportOptions.ExportFormatType = ExportFormatType.PortableDocFormat

oExportOptions.ExportDestinationOptions = oDiskOptions

oReport.Export(oExportOptions)

On your R&D platform, it should be very easy to reproduce:

1. Reference to the assemblies from CRforVS_13_0_12

2.  Build the project in x86

3.  Enable 32-bit in the Application Pool

4.  Viewing report should have no problems.

5.  NOW, change the project configuration to build on x64 platform

6.  Disable 32-bit in the Application Pool

7.  Viewing report should be failed with the exception I mentioned above.

One thing I was reminded and keep you updated that the report files that I was viewing (using the Export() function) were created with the older versions, Crystal 8.5 and Crystal 11.

None of these report files can be viewed on 64-bit but are OK with 32-bit, with the same set of CRforVS_13_0_12 assmeblies referenced to.

Thanks!

[former_member11696 · Accepted solution]

One thing to keep in mind CR 8.5 reports used a different database driver so you should update the rpt file by opening it in CR Designer and update the data driver if required and then verify database and save it in the new format.

It could be both need to be verified first.

The other part is make sure the \temp folder has full read/write permissions.

[former_member1024740 · Accepted solution]

Hi Don,

As mentioned, the same set of assemblies from CRforVS_13_0_12 are working fine on a 32-bit platform, when running the same CR 8.5 or 11 reports.

The existing old (CR 8.5/11) reports are shared and running on both desktop and web applications. There is no plan to upgrade CR for the desktop application.

Since the latest CR (CRforVS_13_0_12) works on the old reports with 32-bit web application, the only thing remaining should be the fix for 64-bit.

I have explained so many times that it works on 32-bit but not on 64-bit. CR 11 reports are not that old to try with, does your R&D ever see the problem? But you did mention earlier:

"There appears to be an issue in SP 12 with Export to Stream which was recently discovered and confirmed by R&D."

So was the fix for my problem being looked into or not yet?  I've been asked for this update almost everyday...

Erica

[former_member11696 · Accepted solution]

Hi Erica,

So try it.. upgrade the reports that don't work to current DB drivers, this will update the 8.5 DB driver to current DB drivers, the driver dll's where renamed and rebuild to crdb_*.dll.

R&D confirmed we do not support Export to Memory Stream is what that bug track is about. May not have anything to do with your issue. So if you are using System.IO.MemoryStream then use System.IO.Stream.

So unless you are willing to test more I can't do anything else. It works for me.

Don

[former_member1024740 · Accepted solution]

I installed Crystal Reports 2013 (version 14.1) which I was told that it is the best matched with SP 12 and upgraded a 8.5 report to this version.  Running this upgraded report on a 64-bit platform threw the same exception.

In my scenario, my code only calls the exposed Export() method while the ExportToStream() is then being called internally by CR engine.  Should your team fix the Export() function so that exporting to memory stream will not be used? 

On 32-bit, I don't need to upgrade the reports and they are all working fine. What does it imply to the ExportToStream() function?

When you said "it works for me", were you or R&D trying with 64-bit platform?

You never mentioned 64-bit in this entire discussion, if ExportToStream() will not be fixed, does it mean that Crystal Reports do not support 64-bit at all even though CRforVS_13_0_12 claims that it supports 64-bit?

This discussion (c# - Can't get a Crystal Report to export - Stack Overflow) seems having the same problem as mine and he ended up having to do everything as 32-bit. 

[former_member11696 · Accepted solution]

Attach one of your reports and I'll test it to see what happens on my 64 test app.

Only Stream issue is if you explicitly export to MemoryStream

[former_member1024740 · Accepted solution]

Attached is the zip file (renamed to .txt as instructed) with upgraded report file.

AFP Detailed Sheet.txt.zip

[former_member11696 · Accepted solution]

Hi Erica,

Thank you but I can't run the report without saved data. Can you attach again with saved data? Use Sample data source of course.

Also, I see your report source is based on a TTX file, you need to update this, that file is no longer supported. Convert your report to use an XML file. You can do that in CR Designer or search for ReplaceConnection in forums and KBA's on how to.

I just posted sample code on how to set your report to XML in this post, don't use the Dataset, too limiting in number of rows of data: http://scn.sap.com/message/15678412#15678412

It would also be good to have the original 8.5 version.

Don

[former_member1024740 · Accepted solution]

Hi Don,

I think you finally pointed out the core problem that TTX is not supported in 64-bit. Probably the report itself is not an issue. I will try with the ReplaceConnection() and see if the problem gets resolved.

Thanks,

Erica

[former_member183750 · Accepted solution]

Hi EErica

Re. ttx files, you may find this blog if use:

- Ludek