Our team recently began having trouble working with SSRS reports in a VS2017 solution. The problem began when I opened up the report solution and was prompted to upgrade the report project files. If I didn’t upgrade them, I couldn’t use them. The project files were upgraded, then no one else on the team could use them.
The problems varied from system to system. Some of the errors said that the project was incompatible. Some said there was an XML error.
There was a lot of comparing systems and troubleshooting. Everyone was sure to have SQL Server Data Tools (15.3 Preview) installed. Some uninstalled and reinstalled this component, but that probably was not a factor.
The two things that really mattered were that the VS Extension for Reporting Services was installed and that it was V1.2 (some had v1.15 and could not open projects until it was upgraded). Those that uninstalled SQL Data Tools had this extension uninstalled automatically and also had to do a repair install on SQL Server Management Studio.
The other issue, was that (most likely) the rptproj.user files were incompatible with the 1.20 extension. Deleting *.rptproj.user files allowed the projects to load.
I recently assisted on troubleshooting an error in a utility application where an exception was being thrown on the dispose of a Microsoft.Reporting.WebForms.ReportViewer. The environmental conditions were pretty specific, so it’s possible you’d never see something like this in your environment. But if you do, here’s how you can work around it.
The specific condition is that we have a shared library of code for both desktop and web applications. One of the functions in that library takes some parameters for an SSRS report and returns a byte array for a rendered PDF of the report. Because the library initially was used exclusively by the website, the WebForms version of the ReportViewer was used. As time went on, the library was used by desktop apps and windows services. That’s when the trouble began.
So, if you are using a WebForms.ReportViewer in a desktop application, you may get this exception when disposing the instance. Digging into the decompiled code for the ReportViewer control suggested it was because there was no HttpContext available. For us, the long-term fix was clear: use the WinForms version of the ReportViewer. In the short term though, adding this line of code resolved the error:
If HttpContext.Current Is Nothing Then HttpContext.Current = New HttpContext(New HttpRequest(IO.Path.GetRandomFileName, "http://www.google.com", ""), New HttpResponse(IO.TextWriter.Null))
This created an HttpContext where there was none before, and the ReportViewer instance was able to be disposed without an error.