This week I came across an issue with the SRS Report Viewer component which I believed we had fixed back in October 2008.... if you cast your minds back you may recall the issue with MS Update KB 956391 and that the update to Kill Bits stopped the Report Viewer's Print functionality. If you don't then read http://blogs.msdn.com/brianhartman/archive/2008/11/05/client-print-fails-to-load-after-microsoft-update-956391.aspx
During the investigation into the issue we found a number of forums also mentioning that the issue had re-occurred so hopefully this helps point people in the right direction and save them time in their investigation.
So back to the client's issue. As with when MS rolled out update KB 956391 if you were to try and print a report you would receive the "Unable to load client print control" error. After reapplying the hotfix KB 954606 and then also upgrading the SQL Server to SP3 without any impact on the issue, I started to look further into the clients configuration.
The clients environment consisted of a front-end Web server which was serving their web site (which includes a front-end custom built report viewer), and also a back-end SQL Server which also has an installation of SRS's Report Manager web interface (and therefore IIS installed) mostly for administration of the report environment. The problem I found was that we were focusing our attention on the SQL Server as an assumption was made that the Report Viewer control was being launched from there. Unfortunately this was not the case, as after checking the clients application I found that their web site (hosted on the front-end web server) actually contained a custom built report viewing tool built in .Net using the Report Viewer component.
Once I had identified that the issue was related to the front-end web site and not the SQL Server, I was then able to track down the following assemblies for the Report Viewer component being servered by their web application's /bin directory, and what I found that these were actually the incorrect versions and were in fact pre hotfix KB954606.
Name: Microsoft.ReportViewer.WebForms.dll
Version: 8.0.50727.42
Name: Microsoft.ReportViewer.Common.dll
Version: 8.0.50727.42
When I compared these to the version of the assemblies in the GAC on the SQL Server I found that these were quite out dated:
Microsoft.ReportViewer.WebForms.dll
8.0.50727.1843
Microsoft.ReportViewer.Common.dll
8.0.50727.1843
TIP: To check the versions of a DLL in the GAC correctly, right click the assembly and open it's properties. Then click the Version tab and the correct version will be reported. The version reported on the General tab and also in the GAC list is not reported correctly.
Once we replaced the out dated DLL's with the latest DLL's from the SQL Server the Print functionality started working again.
On a side note to this I actually found that the Developer had not patched his/her system with either hotfix KB954606 or SP3 for SQL Server and therefore when they published an update to the application they broke the Print functionality again. A lesson should be learnt here to make sure all of your patching is kept up to date, for not only your production systems but also development systems.
To give credit where credit is due this post definitely helped me on my way to identifying the cause.
Thanks Man. You saved me... (-:
ReplyDelete