ASP.Net applications and SQL Server Reporting Services (SSRS)

SSRS is a very convenient tool to generate reports (including charts and tables) on data stored in a database. As usual, convenience or ease of use comes at the price of flexibility. An ASP.NET application allows as much flexibility in data processing and presentation as you can imagine. Intuitively, it would be nice to incorporate SSRS-generated reports in an ASP.NET application to complement each other. There is indeed a control that does exactly this job. It is Microsoft ReportViewer.
There are two ways to use Microsoft ReportViewer: 1. Link it to a report generated by SSRS. 2. Link it to a report generated with Visual Studio and deployed together with an ASP.NET application.
Generating a report in VS is much more awkward than creating an SSRS report. Unless it is improved significantly, it is not worth the time.
Frequently, a report needs to be linked with some information of an ASP.NET page via parameter passing. This can be done by using the method SetParameters of the ServerReport property of MicrosoftReportViewer. One can imagine debugging such a page will not be easy since the report and the ASP.NET page are generated in two different environments, and the report has to be deployed for the ASP.NET to test it, while the SSRS report requires the information of the ASP.NET page to generate the proper report. The challenge is not only this. The sizing of the report can be a significant annoyance. One needs to deal with three sizes: 1. The size of the part (usually a <div> or a table cell) of the MicrosoftReportViewer; 2. The size of MicrosoftReportViewer; 3. The size of the report. What is even worse is that the SSRS report page has some compatibility issues with some browsers. The report can look so obscure that is unusable.
For all the above reasons, it is generally wise not to use SSRS reports in an ASP.NET application.