Preparing to Show SQL Server 2005 Reporting Services with Sharepoint Web Parts

July 27th, 2006

Yesterday I spent a great deal of time preparing to display reports produced with SQL Server 2005 Reporting Services through a Sharepoint Web Part. It was a real chore, so I will now share what I have learned. Here are a few of the critical details.

  • SQL Express 2005 does NOT include Reporting and Integration Services (Standard Edition is the baseline)
  • IIS is required in order to activate Reporting Services (I regrettably had to enable IIS in my .NET 2.0 environment)
  • Microsoft.Sharepoint.dll is required to create the Sharepoint Web Parts
  • A Sharepoint Redistributable SDK is not available so you must extract the above assembly from an installation
  • Sharepoint 2003 cannot be installed on WinXP (the installer prevents it)

I also learned that is a very time-consuming process to go through all of the steps necessary to get the environment ready to do any development. I guess that since I was in a bit of a rush to learn to do this as quickly as possible I skimmed quickly past some documentation which would have been helpful.

Previously I had to set up CruiseControl.NET to build some code for Crystal Reports. I was lucky and found a useful installer in the Visual Studio folder. This time I had to run the Sharepoint install on Windows Server 2003 so that I could get to the Microsoft.Sharepoint.dll assembly. Fortunately I am running Virtual Server on may laptop and have a Windows Server 2003 instance available.

Once I got past these initial requirements I was able to start making real progress. But there were still some problems I worked to overcome. Since I could not run a local Sharepoint installation on WinXP where I have Visual Studio I wanted to create a way to preview these reports. I used the ReportViewer control which I found is available in the Toolbox within the Data tab. My plan is to create a Server Control which programatically loads and sets the properties for the ReportViewer control which can then be dropped nicely into a Sharepoint Web Part for deployment. That way I can have a simple website project for Visual Studio to locally preview the web-based reports while also being easily integrated with Sharepoint.

Deploying to Sharepoint requires a few more steps and details. To get Sharepoint to recognize the new Web Part you must either put it into C:\inetpub\wwwroot\bin with the right trust level, or place it into the Global Assembly Cache (GAC). And to put it into the GAC you must sign the assembly. It seems that most bloggers and developers find dropping the signed assembly into the GAC to be the prefered approach. So I chose to stay with the pack. Once the assembly is deployed you must register your Web Part as a SafeControl and create a Web Part Definition file (.dwp).

To me it still feels like a lot of overhead to simply deploy a web-based report, but once it is done hopefully it will not demand any more hoop jumping. I would personally avoid Sharepoint for this purpose and just make these reports available with a basic ASP.NET 2.0 application using the ReportViewer control. It all depends on whether or not the features which Sharepoint provides are enough to justify the overhead.

Comments are closed.