Crystal Reports With Visual Studio - Issues After Upgrade
Hi all,
We have a bit of a strange issue after an upgrade of SAP Crystal Reports for Visual Studio. All applications have build issues after the upgrade because all of the "CrystalDecisions" DLL's seem to have disappeared after the upgrade.
We were running Version 13.0.10.1385 and all was fine with the DLL's all being located and available for referencing. We upgraded to 13.0.21 and all of the DLL's no longer exist on the machine, and all applications using Crystal Reports now have build errors due to the fact that the CrystalDecisions.CrystalRe
I tested further by removing the new version and replacing the older version and all the issues went away and all was good again. I then reinstalled the new version and the issues come back. There is no error from the install, and it claims that all was successful. I have searched the entire machine and there are no CrystalDecisions DLL files anywhere, so it's not that they have moved them.
It is all very strange ...
Steve
We have a bit of a strange issue after an upgrade of SAP Crystal Reports for Visual Studio. All applications have build issues after the upgrade because all of the "CrystalDecisions" DLL's seem to have disappeared after the upgrade.
We were running Version 13.0.10.1385 and all was fine with the DLL's all being located and available for referencing. We upgraded to 13.0.21 and all of the DLL's no longer exist on the machine, and all applications using Crystal Reports now have build errors due to the fact that the CrystalDecisions.CrystalRe
I tested further by removing the new version and replacing the older version and all the issues went away and all was good again. I then reinstalled the new version and the issues come back. There is no error from the install, and it claims that all was successful. I have searched the entire machine and there are no CrystalDecisions DLL files anywhere, so it's not that they have moved them.
It is all very strange ...
Steve
ASKER
Thanks for that Eric. I will try a repair to see if that addresses my issues.
Steve
Steve
I had the to do a repair only on computers where I was deploying the app - not on my development computer.
ASKER
Ah okay.... I seem to lose all of the DLL's on my development machine after the upgrade.
Steve
Steve
How did you do the upgrade on the development machine?
mlmcc
mlmcc
ASKER
I installed CR 13.0.21.2533 from the downloads, and it said that it would upgrade the existing installation of 13.0.10.1385. That's about it ... The install then ran through, reported success (I did not install the run-time when prompted), and all my DLL's were gone!
Steve
Steve
Are you running the installation with admin privileges? Can you do a test of shutting down your Anti-virus for the time of the installation?
ASKER
Yes, installed from an account with full Admin privs. Will retry with AV shutdown and report back.
Steve
Steve
ASKER
No difference. DLL's gone.
WIth 13.0.10.1385 installed, all of the Crystal Reports DLL's were located in directory
C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\
One example is CrystalDecisions.CrystalRe
After the update to 13.0.21.2533 the path exists in the most part, but the final "dotnet" directory is gone. I have searched the entire development PC for CrystalDecisions.CrystalRe
I am going to have to go back to 13.0.10.1385 and stay there. This new version simply does not work on our machines for some reason.
Might even dump CR totally after this nightmare ...
Steve
WIth 13.0.10.1385 installed, all of the Crystal Reports DLL's were located in directory
C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\SAP BusinessObjects Enterprise XI 4.0\win32_x86\dotnet\
One example is CrystalDecisions.CrystalRe
After the update to 13.0.21.2533 the path exists in the most part, but the final "dotnet" directory is gone. I have searched the entire development PC for CrystalDecisions.CrystalRe
I am going to have to go back to 13.0.10.1385 and stay there. This new version simply does not work on our machines for some reason.
Might even dump CR totally after this nightmare ...
Steve
>>Might even dump CR totally after this nightmare ...
I have been a long time CR user and I am looking into it as well!
Are you installing the developer package from http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_13_0_21.exe?_ga=2.61065964.176562282.1507824215-283503354.1507824215
I have been a long time CR user and I am looking into it as well!
Are you installing the developer package from http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_13_0_21.exe?_ga=2.61065964.176562282.1507824215-283503354.1507824215
ASKER
Yes ... that's the one. I am back at the old version now, but that is what I was installing.
Steve
Steve
ASKER
Okay - update. We have now started the process of dumping Crystal Reports.
The solution is now a .Net application to deal with the interface and all of the grunt work, SQL Server to store the data, and Microsoft Access to generate reports.
With surprisingly little effort we have coded a small routine in .Net that takes two parameters - one of the Report Name, the second of the Parameters to that report. The routine looks up the report in a table to determine the location of the Access Database, and then the code of the routine simply interfaces with the Access database via the Microsoft.Office.Interop.A
In Access all that exists are linked tables, and the report (left set to Default Printer) so that we can override by user.
This is all just proof of concept at the moment, but with about half-an-hour's work we have migrated a report, and have a generic interface to running reports via Access.
I know and accept that this will not be everyone's ideal solution, and that I will likely get lambasted by some, but one thing that Microsoft Access is VERY good at is reports - why not use it for that?
When I have tidied the solution a little I can post example code if anyone is interested, but it definitely works, and works well.
Steve
The solution is now a .Net application to deal with the interface and all of the grunt work, SQL Server to store the data, and Microsoft Access to generate reports.
With surprisingly little effort we have coded a small routine in .Net that takes two parameters - one of the Report Name, the second of the Parameters to that report. The routine looks up the report in a table to determine the location of the Access Database, and then the code of the routine simply interfaces with the Access database via the Microsoft.Office.Interop.A
In Access all that exists are linked tables, and the report (left set to Default Printer) so that we can override by user.
This is all just proof of concept at the moment, but with about half-an-hour's work we have migrated a report, and have a generic interface to running reports via Access.
I know and accept that this will not be everyone's ideal solution, and that I will likely get lambasted by some, but one thing that Microsoft Access is VERY good at is reports - why not use it for that?
When I have tidied the solution a little I can post example code if anyone is interested, but it definitely works, and works well.
Steve
Good for you. But that wouldn't work in my case because I am not using Access as the database. I am thinking of migrating to another engine like Telerik Report from which I have heard good things.
ASKER
Hi Eric,
We are not using Access as the "database", purely as a reporting engine in this case. The data is in SQL Server tables, to which the Access database has links. Luckily we have licenses as we do have Access applications in other areas.
Steve
We are not using Access as the "database", purely as a reporting engine in this case. The data is in SQL Server tables, to which the Access database has links. Luckily we have licenses as we do have Access applications in other areas.
Steve
ok that make sense in your scenario
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Workaround. Problem never solved.
http://emoreau.com/Entries/Blogs/2017/09/Crystal-Reports-SP21-for-VSNet-Issues-with-the-Calibri-font.aspx
http://emoreau.com/Entries/Blogs/2017/09/Crystal-Reports-SP21-for-VSNet-Issues-with-installation.aspx