Showing posts with label 2005. Show all posts
Showing posts with label 2005. Show all posts

Tuesday, April 19, 2011

Using Crystal Reports Basic for VS2008 with VS2005

I had a client for whom I developed a project in Visual Studio 2005. The reports were written for the bundled version 10.2 of Crystal Reports (CR). The application was to be installed on the client's server that already had a number of applications that were using the later Crystal Reports version 10.5 (bundled as Crystal Reports Basic for Visual Studio 2008), a newer version.

Anecdotal evidence showed it was possible to use a version of CR other than what was bundled with VS2005. Unfortunately, no hard documentation existed that defined or instructed one on how to do so. These notes are what I pieced together after a week of intense research and trial & error.

The first thing that must be done is to create and test reports with CR v10.2 that is bundled with VS2005. Easy, right? Of course I'm being sarcastic.

The next step is to install the CR v10.5 runtime package. These can be acquired from several places, the official one being the Crystal Reports page on the SAP Community Network web site. Another source is Visual Studio 2008 Pro, if you have it handy. The x86 package, though, is hidden deep in the bowels of the installation: C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\CrystalReports10_5\CRRedist2008_x86.msi. Install it on your machine; I've encountered no problems with it co-existing with CR v10.2.

Depending on your architecture, you need one of these setup packages:
   CRRedist2008_ia64.msi (64 bit Itanium)
   CRRedist2008_x64.msi (64 bit Intel)
   CRRedist2008_x86.msi (BootStrapper)

In your project, make a list of all references to the CR assemblies and remove them. Here comes the fun part. You can't simply add references to the new assemblies. From a command prompt, go to your %windir%\assembly directory. You will find GAC, GAC_32, and GAC_MSIL directories there. Inside those are subdirectories for each version of the Crystal Reports assemblies on your machine. Copy the 10.5.* version of the DLLs to a folder you create within your project: I called mine CRRedist2008.

In your project, add references by browsing to your CRRedist2008 folder and selecting the same assemblies as were in your original list. Why the copying? Visual Studio does not allow adding references to assemblies in the General Assembly Cache. You need separate files so VS lets you add them as references to your project.

One more step: if you check the reference properties, you may still see the v10.2 assembly being referenced. Set the Use Specific Version property to True to force VS to use the v10.5 assembly you added as a reference.

Recompile and your reports should now run with the VS2008 version of the Crystal Reports libraries.

Barrel of fun, huh?

Tuesday, September 15, 2009

Convincing Visual Studio 2005 that SqlClient is a valid namespace

While getting a project started to connect and use an SQL Server database from a mobile device, I ran into the same problem apparently many others have, too. You had to force Visual Studio to include some framework components so you were allowed to use them. I happened to be using Visual Studio 2005 (aka Visual Studio 8.0) to build an application for a .NET Compact Framework 2.0 platform that exchanged data with a Microsoft SQL Server 2005 database over a wireless network.

To execute a query directly against the remote database without using the SQL Compact (aka SQL Mobile aka SQL CE) SDK and without using dataset objects, required SqlConnection, SqlCommand, SqlParameter, and several other classes that existed in the System.Data.SqlClient namespace. Unfortunately you couldn't just type your using statements and have VS magically link them to your application. You expected Microsoft to make it automatic? No way. That's where the Add Reference... feature is needed and was a source of confusion (days!) in my early development with the VS .NET IDE.

Without adding a proper reference, the statement:

using System.Data.SqlClient;

caused the following compilation error and would not complete the build:

The type or namespace name 'SqlClient' does not exist in the namespace 'System.Data' (are you missing an assembly reference?)

Part of the problem is the multiplicity of .NETCF versions. As is standard with Microsoft, things get moved, renamed, and otherwise mangled between versions. In .NET CF 2.0, SqlClient is part of the System.Data namespace and the System.Data.dll library file; in later versions, there is a separate System.Data.SqlClient.dll. To allow this necessary namespace to be used in your project, you must add a reference to the System.Data.SqlClient component. The trick is learning a couple things about a listed component on the .NET tab: the "Runtime" column identifies the framework version it belongs to, not the "Version" column, that is for the version of the component itself. Also the "Path" column refers to the component as used by the IDE, not by the target device. The path does not even exist on the target device. There were a few clues, but putting them together to arrive at a coherent solution took experience or lots of trials & errors.

At the time I wrote this, the SqlClient namespace for .NET CF 2.0 was added by referencing the component named System.Data.SqlClient, version 3.0.3600.0, runtime version v.0.50727, whose (IDE) path was C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\\SQL Server\Client\v2.0\System.Data.SqlClient.dll. And before you point out my "typo", yes, that was the real path.

Adding this component as a reference finally allowed me to compile without VS coughing up the error.