I was assisting one of my co-authors and colleagues, Jim Pletscher, with Reporting Services 2012 running on our new SharePoint 2013 Farm (so integrated mode of course using the Reporting Services Service Application). We have two (2) dedicated servers that only run Reporting Services.
One issue was that when running a report we would get a connection issue but after hitting F5 (once or twice) the report would eventually render as if nothing was wrong. Therefore I thought maybe one of the Reporting Services servers was acting funny as when one server was accessed it was fine but when the other server was accessed, things weren't right.
We left that one alone as we were getting a similiar issue consistently when attempting to pass parameters into the report rendering via the URL. Investigating the logs, I found the following:
Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'REPORTS_DW'. ---> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
There are tons of posts out there with "System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances" mostly involving .NET Framework 2.0 and Hotfixes. I was sure it couldn't be that.
I stumbled upon a related post but dealing with Excel Services 2010 here where the guy was saying to restart the services. After goofing my Search Service Application previously by trying to restart services, I only totally reboot servers now. So I was going to do that, however, I noticed in the comments of that post that some other guy said restarting the services did not work and that IISReset did the trick.
I was doubtful but decided to try IISReset first on both servers. I waited for the service to come back and I ran the original report without parameters: that worked fine. Next I clicked on the link in the report that contained the report URL with the parameters - it now worked without any issues!
I am glad it was a simple fix but I was hoping for something a little more complex as there is no explanation of why this would happen. If it happens again I am going to suspect an SSRS app pool issue.
One issue was that when running a report we would get a connection issue but after hitting F5 (once or twice) the report would eventually render as if nothing was wrong. Therefore I thought maybe one of the Reporting Services servers was acting funny as when one server was accessed it was fine but when the other server was accessed, things weren't right.
We left that one alone as we were getting a similiar issue consistently when attempting to pass parameters into the report rendering via the URL. Investigating the logs, I found the following:
Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: , Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source 'REPORTS_DW'. ---> System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)
There are tons of posts out there with "System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances" mostly involving .NET Framework 2.0 and Hotfixes. I was sure it couldn't be that.
I stumbled upon a related post but dealing with Excel Services 2010 here where the guy was saying to restart the services. After goofing my Search Service Application previously by trying to restart services, I only totally reboot servers now. So I was going to do that, however, I noticed in the comments of that post that some other guy said restarting the services did not work and that IISReset did the trick.
I was doubtful but decided to try IISReset first on both servers. I waited for the service to come back and I ran the original report without parameters: that worked fine. Next I clicked on the link in the report that contained the report URL with the parameters - it now worked without any issues!
I am glad it was a simple fix but I was hoping for something a little more complex as there is no explanation of why this would happen. If it happens again I am going to suspect an SSRS app pool issue.