RDLC reports and deployment to Godaddy

Question

User-2020366656 posted

Hi,

 

I want to deploy a web application to Godaddy.com. My reports are .rdlc reports. Am I going to have any problems? When I read Microsoft documentation, it says:

"You cannot use .rdlc files in remote processing mode. Remote processing mode requires a licensed copy of SQL Server 2008 or later Reporting Services. Remote processing is intended to support organizations that have a SQL Server Reporting Services report server and want to use that server in conjunction with the controls. A server solution provides better scalability and performance, and offers additional features such as subscriptions, caching, and more report output formats. For more information about remote processing mode, see Configuring ReportViewer for Remote Processing and Deploying Reports and ReportViewer Controls."

 

thanks

Answer 1

User-1528094326 posted

Correct remote processing is for RDL files. The 'C' in RDLC stands for Client, hence the local client processing. You should be fine as long as GoDaddy has the ReportViewer tools installed on your hosting instance, and the client will also have to have the appropriate ReportViewer installed on their system as well. Ideally it will serve up an automatic download though if its configured properly on GoDaddy.

Answer 2

User-2020366656 posted

Well, I talked with the people from Godaddy and seems like they don't have ability to have the reporting programs on their shared hosting server. They say I need to have a virtual dedicated server to install the package and we would have to pay for the license and install the package ourselves. Same with Crystal reports.

So what are my options??? Any recommendations how I could a reporting capability on a Web Hosting company?

thanks!

 

Answer 3

User-1185172246 posted

@N_EvilScott, the client do not need any special software installed! ReportViewer needs to have installed on the server not on the client side. I just want to clarify this. thanks,

Answer 4

User-1528094326 posted

@Neodynamic, unfortunately that's not entirely true. Only Internet explorer actually supports printing functionality using the ReportViewer. Chrome and FireFox as well as Safari last I checked do not support local printing of any kind due to restrictions in the browser.

Furthermore if you want to actually print in Internet Explorer the client must download an ActiveX control that handles the printing operation on the local client. Another problem with this is that only a user with administrative privileges can install the ActiveX control and must be done at least once for every user logged on pretty much depending on your domain setting.

The easiest solution I found was to have an Administrator install the actual ReportViewer package, and that seemed to nip the problem to begin with. Because of these issues, it's actually becoming standard practice to disable a lot of buttons in the ReportViewer toolbar, and then offer up a button to "Save" the report, and then have it Render the report as a PDF in the button_click event handler and serve it up as a download.

If you have full control over the corporate setting, pretty much everything is IE standard due to SSRS requirements within the organization which is by far the most common reporting tool in my field followed by Crystal Reports. However if you just have a website for anyone in the world to view on any browser, you will want to standardize it for sure in some way that works best for you.

Answer 5

User-1528094326 posted

Since you cannot install the package directly to the hosting environment, just create the Bin folder in your web application and copy over the following DLL files.

• Microsoft.ReportViewer.Common.dll
• Microsoft.ReportViewer.WebForms.dll
• Microsoft.ReportViewer.DataVisualization.dll (for graphics and gauges)
• Microsoft.ReportViewer.ProcessingObjectModel.dll

Those alone will do the trick for you, and allow you to use the ReportViewer. You can see a post here that talks about this as well:

http://support.godaddy.com/library/asp-net-reportviewer-with-local-processingmode/

Answer 6

User-2020366656 posted

N_EvilScott,

My customers will be accessing their reports from anywhere on the internet on any platform on any OS. Based on what you mentionned, would I be better off to produce a report with a simple gridview? Half of them are using an IPhone, some are using their Android and some their Windows desktop. I have no control whatsoever on their stations.

thanks

 

acheo

Answer 7

User-1185172246 posted

@N_EvilScott, the user asking for help here was not stating about printing the report but of course, I agree that ReportViewer client-side printing requires ActiveX and this is something that difficults things at the moment of deploying. But again, taking the printing functionality offered by ReportViewer apart, if the developer just want to display the report (and maybe allow PDF export), then the client machine does not need any additional software other than a browser.

Answer 8

User-1528094326 posted

The ReportViewer will work as long as you don't plan on printing from it on anything other than Internet Explorer. Beyond that a common reported problem with using the ReportViewer on mobile devices is that it's very slow to load. I'm not sure if this is still the case with newer phones and more modern browsers, but it's something you might want to test or keep in mind.

As I mentioned above if the ReportViewer is what you want and like, then just remove the print button entirely and the toolbar buttons in general if you want besides navigation, and then just make your own custom export method that will shove it into a PDF and let the client decide how to print it.

If you want to go another route, then you'll be looking at a report engine similar to maybe what Gmail and Outlook.com use? I don't think that engine is free though.

Answer 9

User-1528094326 posted

@Neodynamic, Reporting in general is a business line process that includes generating and printing reports. Exporting the reports is a relatively new phenomenon and convenience. The question above was about reporting in general, thus the idea of printing is still included by default. My main goal by advising him of the extra step was just to save him time by having him know exactly what he's getting into. It's not fair to him if he implements everything in SSRS and then comes back a month later with the problem of "Why can't I print in anything other than IE?!?!?!"

Answer 10

User-2020366656 posted

thankss N_EvilScott,

You were right, I have intention using the RDLC if printing is an issue on some platforms. Thanks to eveeryone that was fery informative and I will discard thiss option immediately.

Answer 11

User-2020366656 posted

N_EvilScott

I checked the link you gave in reference and have a hard time to figure how to change the Web.config file. Couls you help me?

ps So far I find deploying an ASP.NET application on a third party a lot of troubles.

thanks