I was debugging a problem with SharePoint 2007 Site Usage reports on a client farm and I finally figured out the problem.
Out of the box, SharePoint 2007 uses Report Viewer controls to render Site Usage reports. These reports target Report Viewer version 8 assemblies which correspond with the Visual Studio 2005 report designer. In the recent past we deployed some reports which were designed in Visual Studio 2010. To support these reports, the SharePoint web.config was modified to use the Report Viewer version 10 assemblies. This worked to get the new reports to render but a few days later it was discovered the Site Usage reports were no longer working.
The error we received complained of a missing Script Manager on the page. Version 8 and 9 didn’t do any asynchronous activities so there was no need for the pages to have it. Hoping this could be a quick fix, one of the devs modified the application.master page to insert a script manager. This did not result in success. Another error, which I never captured, was shown instead. A much more ominous error.
Taking a step back we saw other custom reports deployed in the past which didn’t affect the site usage reports. Turns out they were designed with Visual Studio 2008 which use the version 9 assemblies. The site usage reports would run just fine with the version 9 HttpHandler but refused to work under 10.
After much searching of the Internet I was able to find resource after resource about getting Report Viewer version 8 and 9 to live together in harmony on a SharePoint farm but I could find nothing about jamming version 10 in there as well. The problem is all versions use the same path to register a handler: Reserved.ReportViewerWebControl.axd. Only one handler can be active at a time. Our exploration of compatibility showed we needed both version 9 and 10 to cover all the possibilities (so far).
Since only one handler can be registered at a time, I attempted to write my own that would examine the request and forward the call to the proper runtime. Alas this also failed due mostly to needed to use binding redirects in the webconfig which overrode the assembly version I tried to select with the custom handler.
In the end we went with a brute-force approach. We opened every SharePoint OOB report in the VS 2008 and allowed it to upgrade the reports. Then we did the same in 2010. Only one report failed to convert properly though I can’t remember the exact error – basically a character was outside the XML tags and caused the parser to throw a fit. That was a quick fix. Once this was done, all the web.config files (central admin included!) could be updated to use the version 10 http handler and binding redirect and all our custom v9 and v10 reports along with the converted SharePoint reports worked as expected.
It’s been a couple months since I first started this blog post and found my initial solutions didn’t work. The brute force solution did work for us and has been in place for almost that same amount of time with no errors or performance issues as far as we can tell.
It may not be the cleanest approach but at this point it’s very unlikely the OOB reports were going to be changed by any more service packs. It was a calculated risk and one that let us move forward with our tool sets and not artificially constrain our work.
*Note(11/7/2011): This post was written months ago (6/30/2011) with a solution that had ultimately not worked. It’s been almost as long since the working solution was put in place but I hadn’t come back to correct the post and publish it. I’m rectifying that today. The solution presented is the current solution our client is using. I only point this out in case of incongruity in the voice or tone of the post. I didn’t feel like re-writing the whole thing since, again, it was months ago when it happened.