Face it, upgrading versions can be a major pain in the butt. Especially when it involves moving third-party stuff like Crystal Reports from Dev to QA to Production. The wrong library, or a missing library, causes the whole thing to crash to a halt.
And so it was recently when I upgraded my development environment from Visual Studio 2008 to VS 2010. (I know, kind of late isn’t it? But such is life. ) That necessitated upgrading Crystal Reports from 2008 (internal version 12) to “Crystal Reports for Visual Studio 2010” (Version 13.0.2 SP2).
Here is the situation: there is my Dev machine, a QA server, and a Production server. For a long time, all the apps were developed and deployed with .NET 2.0 and VS 2008. A new app making its way through QA uses VS 2010 and .NET 4.0, along with the new Crystal Reports. In addition, I have decided to upgrade one of our two websites to the new versions as well.
Getting this all to work without breaking the “unchanged” website has proven quite a challenge. So far, I have been navigating the pitfalls on the QA server. Hopefully, when the changes finally reach production, we will have ironed out all the hitches.
The Dev Machine
After installing VS 2010 on my Dev machine (leaving VS 2008 in place, which still works fine), I went to the SAP Crystal Reports website, downloaded “Crystal Reports for Visual Studio 2010” which integrates into VS, and installed that. (My recollection was that it was covered by a prior purchase of CR 2008, but I can’t say for sure. The main landing page for CR for VS on the SAP website is at http://www.sdn.sap.com/irj/sdn/crystalreports-dotnet.)
The upshot was a new folder in c:\Program Files. Whereas CR2008 lived in c:\Program Files\Business Objects, the new stuff lives in C:\Program Files\SAP BusinessObjects.
Here is a screen shot of the CR 2008 folders in Program Files (sanitized a bit):
Here are the equivalent folders for the new version of Crystal Reports. It looks like they call it “Crystal Reports 2011”, although it goes w/ Visual Studio 2010. And the internal version is 13, although you can’t see that from this screenshot.
Note that in the previous version, the highlighted folder is called crystalreportviewers12 while in the newer version it is just crystalreportviewers, with no version number. That becomes a point of confusion later.
Now when I open a web site which uses Crystal Reports, if it has not done so already, VS offers to convert the solution, with this dialog.
If VS detects the web site itself is from an earlier version of .NET, it offers this as well:
The upshot of all this is that web.config is significantly shortened (a number of sections are no longer included) and all the references in it to Crystal libraries are modified with the updated version, as in:
<add assembly=”CrystalDecisions.CrystalReports.Engine, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304″/>
In addition, the @Register directive on all the pages which use Crystal Reports components is updated, as in:
<%@ Register assembly=”CrystalDecisions.Web, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304″ namespace=”CrystalDecisions.Web” tagprefix=”CR” %>
New web sites, of course, just use the new stuff.
So far, so good. Now you can develop or maintain your web site with Crystal Reports components and it works great in Dev. Then comes…
Once deployed to a server, things look quite a bit different.
First you have to download and install the Crystal Reports redistributable. I downloaded and installed this file from the CR web site. I clicked on the “Redist Install 32-bit” link under Support Pack 2 to download CRforVS_redist_install_32bit_13_0_2.zip, which I then installed on the server.
It inserted the same folders under Program Files shown above for the Dev machine. However, they are not actually used. Instead, there is a new folder called aspnet_client, that needs to be installed into the virtual root of the website, as shown in this screen shot of the root directory for the web site..
Note that the crystalreportviewers folder now has the number 13 appended.
Where did this folder come from? When the redistributable is run on the server, it puts a copy of this folder in the default web site virtual root, i.e. c:\inetpub\wwwroot. You just have to know to copy it to each of your website root directories, if they are different from inetpub.
Then when you deploy the updated web site, most critically with the updated web.config, it should all work.
There are a few things to consider;
1) When running the app on the development computer, you have the option of running the app under File System (Cassini) or HTTP. When choosing File System, the viewer used will be from the C:\Program Files (x86)\SAP BusinessObjects\Crystal Reports for .NET Framework 4.0\Common\Crystal Reports 2011\crystalreportviewers directory.
Using HTTP, the directory will be C:\inetpub\wwwroot\aspnet_client\system_web\4_0_30319\crystalreportviewers13
2) On deployment, the MSI / MSM does not know if an app will be installed under default or custom app pool. Even if it knew an app would go under a custom app pool, it would have no idea which one. So, the viewer is / should be installed and configured under the default app pool (pointing to C:\inetpub\wwwroot\aspnet_client\system_web\4_0_30319\crystalreportviewers13).
So there you have it. I hope this is helpful.