Coexistence of Report Viewer Versions 8.x and 9.x in SharePoint

In one of our clients' SharePoint environments, both Report Viewer version 8.x and Report Viewer 9.x were installed. The assemblies can live together in the Global Assembly Cache (GAC) because of the different versions. The development team had created a custom reporting interface solution using the Report Viewer 9.x version(s) of the assemblies and controls. In order for the pages to render properly, an entry under HTTP Handlers within the web configuration (web.config) was required:

<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

This was fine. However, the SharePoint usage report page would not render because it requires the Version 8.0.0.0 HTTP Handler entry. The error message actually stated that that the line was missing. It wasn't missing, it was in there:

<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

It came first in the HTTP Handler section and we quickly realized that the last entry for the same path wins the battle. There seems to be no way of having two HTTP Handlers for the same path (which make sense). So in our case, either the custom reporting solution was broken or the Site Usage reports would not work; this would not be acceptable for long.

I needed to find away to have both Version 8.0.0.0 and Version 9.0.0.0 work within the same web application. I tried various configuration settings and "hacks" in attempt to get it to work until finally I noticed something in the Reporting Services web config. There was some sort of an assembly redirect to tell IIS (ultimately) to use a different version of an assembly. It wasn't the assembly I was dealing with but I figured I may be able to use the same approach.

Therefore, within the SharePoint web.config for port 80, I entered the following within the <runtime> <assembly binding> section under the <system.web> settings :

<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportViewer.WebForms" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="8.0.0.0"
newVersion="9.0.0.0"/>
</dependentAssembly>

Essentially, this was telling SharePoint that "if you are looking for the 8.0.0.0 version, use the 9.0.0.0 instead". This allowed the Site Usage page to at least render! It rendered with all of the web parts however the web parts all contained the same error message. They were now looking for the 9.0.0.0 version of the Microsoft.ReportViewer.ProcessingObjectModel assembly which didn't exist. I looked in the GAC and there was only the Version 8.0.0.0 in there. So I figured this was probably deprecated with the latest Report Viewer updates for SharePoint.

So I decided to be tricky and use the same redirect for the Microsoft.ReportViewer.ProcessingObjectModel assembly but using the opposite version settings:

<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportViewer.ProcessingObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="9.0.0.0"
newVersion="8.0.0.0"/>
</dependentAssembly>

This actually worked! The Site Usage reports rendered and the development team's custom reporting interfaces were still functioning. We thought we were going to have to apply MOSS 2007 SP2 and/or SQL Server SP3 and worse case open a case ticket with Microsoft Support - not anymore!

3 comments:

Sean said...

Thank you very much for this information it was a great help to us.

We have encountered another issue with the report viewer and the \n escape sequence. Maybe you guys can share some light on it?

On a graph if one of the labels is say for instance somecollection\numberofitems the graph is recognising the \n and transforming this into:
somecollection
umberofitems

Is there any way to stop this we have tried various escape sequences.

Anonymous said...

Thank you very much it worked for me.

Ayman M El-Hattab said...

Worked like a charm :)