Having just recently successfully installed the current release of SSDT-BI (the current version as of this writing is based on SQL Server 2014 32-bit and the Visual Studio 2013 Integrated Shell), it was time to finally open up some SSRS (SQL Server Reporting Services) projects and get to work.
For anyone that use used the report Preview button within SSDT-BI, you know getting it to work can be a bit dicey. Microsoft has changed the internal behavior of what happens behind the scenes when the preview button is pressed, and that has created a number of problems.
No surprise, the first time I pressed the preview button, I was greeted with this:
Well, that’s not good. I should preface this by saying that I did two significant things to ultimately resolve this issue. It’s possible that only the second one was needed, but I’m going to list them both (as well as a workaround) just in case it’s helpful.
The report I was using to test with uses shared data sets, which in turn use shared data sources. Also, one of these shared data sources has credentials stored with it (instead of using integrated windows authentication). When project files are copied over, the stored passwords don’t come with so the first fix is simply to check your data sources for any saved passwords and re-enter them if there are. The error message given is entirely unhelpful, but that may have been the only fix needed.
This may not be an issue in the current release of SSDT-BI, but it certainly was in the previous release. The report Preview function launches a process to serve the rendered report. Previously, and possibly still, that process requires the Net.Tcp Listener Adapter service to be installed and Running. If you have it installed, but not running, set it to Automatic and start it.
What’s that? You don’t have a Net.Tcp Listener Adapter service? I didn’t either. It turns out, on Windows 10, this isn’t installed by default with the rest of .NET 4.6 and you need to add it via Programs and Features -> Turn Windows features on or off
Make sure Named Pipe Activation and TCP Activation are checked under .NET Framework 4.6 Advanced Services -> WCF Services. Once you press Ok the features will install and you will be prompted to reboot. Following the reboot, you should now have the Net.TCP Listener Adapter service listed in Services and it should be Running.
With that, you should now be able to launch the report Preview
In addition to the two items above (one or both of which fixed my issues) there is a workaround that can be used as well. Despite being a workaround, this is actual useful as the rendering engine may give different or better error messages than the Preview engine (for example, this engine gave me a detailed error message telling me my data sources had credentials issues, whereas the preview engine just mentioned that an error had occurred)
To implement the workaround, simply right click on a report and select Run. But wait. Don’t do this if you typically publish your reports to a SharePoint site in SharePoint integrated mode…
If you don’t publish reports to a SharePoint site in SharePoint integrated mode, it’ll render the report in a new local preview window. If, however, you publish reports to SharePoint, when you press the run button, it’ll upload the reports to SharePoint and then render them via SharePoint in a browser window. Not at all what we want.
Since SSDT-BI is based on Visual Studio, it has a number of profiles built in, such as Debug, DebugLocal, and Release. As a workaround for the SharePoint issue, you can edit one, such as DebugLocal by right clicking on your Solution in the upper right Solution Explorer and selecting Properties. Select Configuration in the Configuration Properties section of the window and then change the Configuration item in the top dropdown box to DebugLocal. Finally, uncheck the Deploy checkbox for any projects you have within the solution.
You can now use DebugLocal for local previews and continue to use Debug and Release for actual deployments. Additionally, at this point, you should be able to preview SSRS reports locally either with the inline Preview button or with the Run button and can use either one as a matter of preference, though keep in mind that the Run window may provide more robust error messages for some issues.