January 18, 2021 at 12:00 am
Comments posted to this topic are about the item Using an RDL File Locally in .NET to Print Reports
January 18, 2021 at 11:58 am
Same thing can be done in PowerShell.
https://audministrator.wordpress.com/2019/05/05/powershell-retreive-a-ssrs-report-in-a-net-gui/
Enjoy !
January 18, 2021 at 1:10 pm
Hi,
Thanks for sharing the link. Actually, your link on using powershell isn't actually the same thing. That article shows how to call a SSRS report using a reporting server URL. At the bottom of the article it talks about being able to call a report local, but there is no example of it in powershell.
Thanks for your comment.
Ben
January 18, 2021 at 3:30 pm
Good article, Ben. You touch upon a problem I've encountered over the last 4 years at work. I'm on a team that's slowly working on replacing incredibly old Excel and MS Access apps with a Windows equivalent. Some of these require duplicating reports. We've always chosen SSRS as the technology to replace them with. When we do this, for reasons I've never understood my colleagues like to include the Microsoft.SqlServer.Types.dll into the deployment package. (I've asked why they do this, but they never answer me. No matter, going on.) The problems with this approach are as follows. (a) We're stuck at God only knows what outdated version of the Microsoft.SqlServer.Types.dll they copy one from project to another. (I don't know where they started copying that DLL from, as that's before I joined the team almost 6 years ago.) (b) Since we use ClickOnce deployment, including Microsoft.SqlServer.Types.dll. This is a problem because Microsoft.SqlServer.Types.dll must be installed using elevated privileges. (It must be installed in the GAC, which requires administrative privileges.) None of the users installing any of the apps we install using ClickOnce, are administrators on their machines. Thus, the users always encounter an error during installation and they always blame me. I learned 4 years ago that the issue was including Microsoft.SqlServer.Types.dll into the deployment. So, I'd remove it so ClickOnce could work. Then my colleagues would just put it back in again. Although I've told them repeatedly of the installation problems this causes, they ignore me and continue to put Microsoft.SqlServer.Types.dll back into the ClickOnce deployment. This results in a vicious cycle, but I'll stop here describing.
About 4 years ago I decided to investigate what Microsoft.SqlServer.Types.dll does. I learned that it was to help C# work with the SQL Server's spatial types, such as SQLGeography and so on. C# doesn't include this data type, so Microsoft.SqlServer.Types.dll provides the bridge between the two. At that time, I thought, why are we including a DLL to work with a data type that isn't used in our databases? I took this to be a justification for removing Microsoft.SqlServer.Types.dll in the first place.
However, more recently I thought perhaps Microsoft did it this way, just in case, the local RDL report used a SQL Server spatial data type. I can understand this logic, so that makes sense of the situation. If I'm correct about this, then I really wish Microsoft had some sort of flag that the developer could set, saying "This report using SQL Server Spatial Data Types" or clear it otherwise. As far as I know, there isn't such a flag.
Sorry, long explanation. But at least you see the dilemma I'm in. This brings me to ask you a few questions. Early in your article, you said you used the NuGet package Microsoft.ReportingServices.ReportViewerControl.WebForms, instead of the WinForms version. Why do you do this? Is it to avoid the problem I've encountered? I've seen both packages on NuGet. I thought that if I did use either NuGet package, I'd use the WinForms version, because we're working with Windows apps, not Web apps. However, I don't use either NuGet package because for some reason, which again my colleagues will not tell me, they abhor using NuGet and want to include DLLs directly in their applications. Would using the Microsoft.ReportingServices.ReportViewerControl.WebForms NuGet package solve my problem of being able use SSRS reporting locally without having to install the Microsoft.SqlServer.Types.dll in the GAC?
Rod
January 18, 2021 at 3:45 pm
Hi,
Thanks for your question. I wish I knew the exact answer to your question, but this is what I can tell you. I use the webforms dll to render the reporting services report locally because the call to the render method is simple. The webforms method looks like this:
Byte[] mybytes = report.Render("PDF");
You can just pass in the output format. Since I am not actually using any of the visual controls or anything like that there is no issue using the webforms dll in a winform application.
So if you are showing the report in a report control in your winforms application, your only option is to use the winforms reporting services dll.
The render method in the winforms dll looks like this:
public byte[] Render (string Format, string DeviceInfo, out string Extension, out string MimeType, out string Encoding, out ReportExecution2005.Warning[] Warnings, out string[] StreamIds);
So you can see in the call you have to pass in a bunch of 0ut parameters that don't actually matter if you are just trying to export to PDF.
Anyway, not sure if that is helpful or not, but that is what I know.
Thanks,
Ben
January 18, 2021 at 8:19 pm
Not sure I follow the value in using an RDL locally as opposed to converting to an RDLC and using the ReportViewer. In fact, I think there's very little if any difference between the data to convert to an RDLC.
January 18, 2021 at 8:24 pm
The benefit is that I don't want to use the report viewer. I don't want to display the report. I have the requirement of printing.
The local report with a RDL allows me to directly create a PDF that can be printed with no Reportviewer.
Thanks,
Ben
January 19, 2021 at 3:16 pm
Hi,
Thanks for your question. I wish I knew the exact answer to your question, but this is what I can tell you. I use the webforms dll to render the reporting services report locally because the call to the render method is simple. The webforms method looks like this:
Byte[] mybytes = report.Render("PDF");
You can just pass in the output format. Since I am not actually using any of the visual controls or anything like that there is no issue using the webforms dll in a winform application.
So if you are showing the report in a report control in your winforms application, your only option is to use the winforms reporting services dll.
The render method in the winforms dll looks like this:
public byte[] Render (string Format, string DeviceInfo, out string Extension, out string MimeType, out string Encoding, out ReportExecution2005.Warning[] Warnings, out string[] StreamIds);
So you can see in the call you have to pass in a bunch of 0ut parameters that don't actually matter if you are just trying to export to PDF.
Anyway, not sure if that is helpful or not, but that is what I know.
Thanks,
Ben
Hi Ben,
I'm now replying from my work account.
Yes, we need to have the WinForms version, because we are using the report viewer control. The users want to be able to see the report in the application, where they can decide to either look at it or export it to PDF, Excel, etc.
One of my colleagues is trying to use the WinForms NuGet package. At least it's not depending upon the .DLL being included, which as I've said is nothing more than a disaster and never works. We'll see this week if that works at all, as we'll release a ClickOnce version that includes it.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply