How to do a simple RDLC report using Visual Studio

RDLC (Report Definition Language Client-side)

1. What is RDLC Reporting service?

RDLC stands for Report Definition Language Client-side. RDLC can be run completely client-side in the ReportViewer control. This removes the need for a Reporting Services instance, and even removes the need for any database connection whatsoever; but it adds the requirement that the data that is needed in the report has to be provided manually. RDLC reports do not store information about how to get data. RDLC reports can be executed directly by the ReportViewer control.

2. RDL VS RDLC

DL files are created by the SQL Server 2005 version of Report Designer. RDLC files are created by the Visual Studio 2008 version of Report Designer.RDL and RDLC formats have the same XML schema. However, in RDLC files, some values (such as query text) are allowed to be empty, which means that they are not immediately ready to be published to a Report Server. The missing values can be entered by opening the RDLC file using the SQL Server 2005 version of Report Designer. (You have to rename .rdlc to .rdl first.).

RDL files are fully compatible with the ReportViewer control runtime. However, RDL files do not contain some information that the design-time of the ReportViewer control depends on for automatically generating data-binding code. By manually binding data, RDL files can be used in the ReportViewer control. New! See also the RDL Viewer sample program.

The ReportViewer control does not contain any logic for connecting to databases or executing queries. By separating out such logic, the ReportViewer has been made compatible with all data sources, including non-database data sources. However this means that when an RDL file is used by the ReportViewer control, the SQL related information in the RDL file is simply ignored by the control. It is the host application's responsibility to connect to databases, execute queries and supply data to the ReportViewer control in the form of ADO.NET Data Tables.

RDL Much better development experience, more flexibility if you need to use some advanced features like scheduling, ad-hoc reporting, etc... RDLC (Local reports): Better control over the data before sending it to the report (easier to validate or manipulate the data prior to sending it to the report). It has much easier deployment and no need for an instance of Reporting Services.

One HUGE drawback with local reports is a known memory leak that can severely affect performance if your clients will be running numerous large reports. This is supposed to be addressed with the new VS2010 version of the report viewer.

3. How to create a RDLC report in VS 2008?

Step1: Creating Client Report Definition (.rdlc) Files.

There are many ways for creating rdlc files. Follow any of these methods for creating rdlc file Create a new client report definition (.rdlc) file in Visual Studio. Convert an existing RDL file to rdlc or create rdlc file programmatically. I am dealing here only on creating new rdlc from VS.

Select “Add new item” and select report/report wizard

Selecting report will add an empty rdlc file whereas wizard will lead you to create a report with data connection.

MyReport.rdlc is added to the solution explorer.

IF you are using report wizard, follow the following steps..

Create connection string

Save connection string to web.config file

Choose your stored procedure/table/query

Add fields to the report

Complete the wizard

Step2: Creating a dataset.

Select “add new item” to add a dataset to the project

Add the new dataset to the app_code folder

Step3: Drag Table Adapter & Use the configuration wizard to configure the dataset.

Select connection string

Select one from the options given

Solution explorer updated with dataset

Instead of dataset you can also use object DataSource as data source of rdlc file.

Step4: Adding DataSource to Report

Open rdlc file in the design view, Click on “Show data sources “under the “Data” menu item and you can simply drag and drop fields to the report.

Drag and drop a table from tool box.

Click on Reports→Data sources to add data sources to the report

Drag and drop the fields you wanted on the detail section of the table.

Add footer if need.

Place whatever controls you want on the report and drag field to its expression

You have a couple of categories from which you can have data for the expression.

Under global we have:

Under parameter we have all the parameters you have added to the report.

Step5: Adding Parameters to Report

To communicate between the UI and the report, use parameters.

To add parameter use Reports-> report parameters… menu item

          Rdlc file and the dataset are ready and we can show the report in the web page. You can set the page properties using Report properties dialog
       
   
        Step6: Adding rdlc on aspx page

Add a new aspx page and drag a report view control on it. Use the smart tag to choose report. Once you add the report,

Report source as well can be configured.

    Step7: Run the web page and you will be able to view the report.
   

           Step8: How to attach DataSource dynamically from C# to rdlc file
   

Step9: How initialize parameters from C# to rdlc file

     // parameters are initialized for the report
     ReportParameter Param0 = new ReportParameter("fromDate", fromDate.ToString(dateFormat));
     ReportParameter Param1 = new ReportParameter("toDate", toDate.ToString(dateFormat));
     ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { Param0, Param1 });

Step9:  Deployment Note.

1. Add the following key to handler section of the web.config file

<handlers>

         <add name="Reserved-ReportViewerWebControl-axd" path="Reserved.ReportViewerWebControl.axd"
         verb="*" type="Microsoft.Reporting.WebForms.HttpHandler,Culture=neutral"  resourceType="Unspecified"/>      
     </handlers>

2. You may get this error “Server Error in '/' Application.

Could not load file or assembly 'Microsoft.ReportViewer.WebForms, Version=8.0.0.0' or one of its dependencies. The system cannot find the file specified.”. To solve this mannually copy the following files to the bin folder of your website.

Please make sure you have .NET Framework 3.5 installed on the computer.

When you run ReportViewer.exe, the following files are installed in the Global Assembly Cache folder on the deployment computer.

Microsoft.ReportViewer.Common.dll

Microsoft.ReportViewer.ProcessingObjectModel.dll

Microsoft.ReportViewer.WebForms.dll

Microsoft.ReportViewer.WinForms.dll

Microsoft.ReportViewer.DataVisualization.dll

The error indicates that the system cannot load Microsoft.ReportViewer.Webforms. Please try to manually copy the Microsoft.ReportViewer.WebForms.dll file to the application folder /bin directory. Please refer to the following link for more information about the Report Viewer.

http://msdn.microsoft.com/en-us/library/ms251723.aspx

3. If you are publishing the webstie using framework 3.5 use “Allow this precompiled site to be updatable.

  

I found the following sites to be very useful while working with RDLC reporting    

http://www.ssw.com.au/ssw/standards/rules/rulestobetterSQlreportingservices.aspx  

http://aspalliance.com/articleViewer.aspx?aId=914&pId=-1

http://msdn.microsoft.com/en-us/library/xt50s8kz.aspx

http://technet.microsoft.com/en-us/library/ms157328.aspx

Biju Joseph

Reading MailSetting from web.config

System.Configuration.
System.Net.Configuration.

{
}Configuration mailConfig = System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(HttpContext.Current.Request.ApplicationPath);MailSettingsSectionGroup mailSettings = (System.Net.Configuration.MailSettingsSectionGroup)mailConfig.GetSectionGroup("system.net/mailSettings");if (mailSettings != default(MailSettingsSectionGroup))

Understanding ASP.NET Basics

ASP.NET is a Web application framework developed and marketed by Microsoft to allow programmers to build dynamic Web sites, Web applications and Web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft's Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Run time (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages.

Pages

ASP.NET Web pages, known officially as Web Forms, are the main building block for application development. Web forms are contained in files with an ".aspx" extension; these files typically contain static (X) HTML markup, as well as markup defining server-side Web Controls and User Controls where the developers place all the required static and dynamic content for the Web page. Additionally, dynamic code which runs on the server can be placed in a page within a block 
<% -- dynamic code -- %>, which is similar to other Web development technologies such as PHP, JSP, and ASP. With ASP.NET Framework 2.0, Microsoft introduced a new code-behind model which allows static text to remain on the .aspx page, while dynamic code remains in an .aspx.vb or .aspx.cs or .aspx.fs file (depending on the programming language used).

Directives

A directive is special instructions on how ASP.NET should process the page. The most common directive is <%@ Page %> which can specify many attributes used by the ASP.NET page parser and compiler

Inline-Code solution

Code-behind solutions

<%@ Page Language="C#" CodeFile="SampleCodeBehind.aspx.cs" Inherits="Website.SampleCodeBehind" AutoEventWireup="true" %>

The above tag is placed at the beginning of the ASPX file. The CodeFile property of the @ Page directive specifies the file (.cs or .vb or .fs) acting as the code-behind while the Inherits property specifies the Class from which the Page is derived. In this example, the @ Page directive is included in SampleCodeBehind.aspx, then SampleCodeBehind.aspx.cs acts as the code-behind for this page:

User controls

User controls are encapsulations of sections of pages which are registered and used as controls in ASP.NET. User controls are created as ASCX markup files. These files usually contain static (X) HTML markup, as well as markup defining server-side Web controls. These are the locations where the developer can place the required static and dynamic content. A user control is compiled when its containing page is requested and is stored in memory for subsequent requests. User controls have their own events which are handled during the life of ASP.NET requests. An event bubbling mechanism provides the ability to pass an event fired by a user control up to its containing page. Unlike an ASP.NET page, a user control cannot be requested independently; one of its containing pages is requested instead.

Custom controls

Programmers can also build custom controls for ASP.NET applications. Unlike user controls, these controls do not have an ASCX markup file, having all their code compiled into a dynamic link library (DLL) file. Such custom controls can be used across multiple Web applications and Visual Studio projects.

Rendering technique

ASP.NET uses a visited composites rendering technique. During compilation, the template (.aspx) file is compiled into initialization code which builds a control tree (the composite) representing the original template. Literal text goes into instances of the Literal control class, and server controls are represented by instances of a specific control class. The initialization code is combined with user-written code (usually by the assembly of multiple partial classes) and results in a class specific for the page. The page doubles as the root of the control tree.
Actual requests for the page are processed through a number of steps. First, during the initialization steps, an instance of the page class is created and the initialization code is executed. This produces the initial control tree which is now typically manipulated by the methods of the page in the following steps. As each node in the tree is a control represented as an instance of a class, the code may change the tree structure as well as manipulate the properties/methods of the individual nodes. Finally, during the rendering step a visitor is used to visit every node in the tree, asking each node to render itself using the methods of the visitor. The resulting HTML output is sent to the client.
After the request has been processed, the instance of the page class is discarded and with it the entire control tree. This is a source of confusion among novice ASP.NET programmers who rely on class instance members that are lost with every page request/response cycle.

State management

ASP.NET applications are hosted by a Web server and are accessed using the stateless HTTP protocol. As such, if an application uses stateful interaction, it has to implement state management on its own. ASP.NET provides various functions for state management. Conceptually, Microsoft treats "state" as GUI state. Problems may arise if an application needs to keep track of "data state"; for example, a finite-state machine which may be in a transient state between requests (lazy evaluation) or which takes a long time to initialize. State management in ASP.NET pages with authentication can make Web scraping difficult or impossible.

Application

Application state is held by a collection of shared user-defined variables. These are set and initialized when the Application_OnStart event fires on the loading of the first instance of the application and are available until the last instance exits. Application state variables are accessed using the Applications collection, which provides a wrapper for the application state. Application state variables are identified by name.

Session state

Server-side session state is held by a collection of user-defined session variables that are persistent during a user session. These variables, accessed using the Session collection, are unique to each session instance. The variables can be set to be automatically destroyed after a defined time of inactivity even if the session does not end. Client-side user session is maintained by either a cookie or by encoding the session ID in the URL itself.


ASP.NET supports three modes of persistence for server-side session variables:
In-Process Mode
The session variables are maintained within the ASP.NET process. This is the fastest way; however, in this mode the variables are destroyed when the ASP.NET process is recycled or shut down.
ASPState Mode
ASP.NET runs a separate Windows service that maintains the state variables. Because state management happens outside the ASP.NET process, and because the ASP.NET engine accesses data using .NET Remoting, ASPState is slower than In-Process. This mode allows an ASP.NET application to be load-balanced and scaled across multiple servers. Because the state management service runs independently of ASP.NET, the session variables can persist across ASP.NET process shutdowns. However, since session state server runs as one instance, it is still one point of failure for session state. The session-state service cannot be load-balanced, and there are restrictions on types that can be stored in a session variable.
SqlServer Mode
State variables are stored in a database, allowing session variables to be persisted across ASP.NET process shutdowns. The main advantage of this mode is that it allows the application to balance load on a server cluster, sharing sessions between servers. This is the slowest method of session state management in ASP.NET.

View state

View state refers to the page-level state management mechanism, utilized by the HTML pages emitted by ASP.NET applications to maintain the state of the Web form controls and widgets. The state of the controls is encoded and sent to the server at every form submission in a hidden field known as __VIEWSTATE. The server sends back the variable so that when the page is re-rendered, the controls render at their last state. At the server side, the application may change the view state, if the processing requires a change of state of any control. The states of individual controls are decoded at the server, and are available for use in ASP.NET pages using the View State collection.
The main use for this is to preserve form information across post backs. View state is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a postback. This behavior can (and should) be modified, however, as View state can be disabled on a per-control, per-page, or server-wide basis.
Developers need to be wary of storing sensitive or private information in the View state of a page or control, as the base64 string containing the view state data can easily be de-serialized. By default, View state does not encrypt the __VIEWSTATE value. Encryption can be enabled on a server-wide (and server-specific) basis, allowing for a certain level of security to be maintained.

Server-side caching

ASP.NET offers a "Cache" object that is shared across the application and can also be used to store various objects. The "Cache" object holds the data only for a specified amount of time and is automatically cleaned after the session time-limit elapses.

Other

Other means of state management that are supported by ASP.NET are cookies, caching, and using the query string.

Other files

Other file extensions associated with different versions of ASP.NET include:

Extension	Introduced in version	Description
asax	1.0	This is global application file.You can use this file to define global variable(Variable that can be accessed from any Web page in the Web application.) It is mostly used to define the overall application event related to application & session object.Global.asax, used for application-level logic
ascx	1.0	User Control, used for User Control files logic
ashx	1.0	custom HTTP handlers Do not have a user interface.
asmx	1.0	Web service pages. From version 2.0 a Code behind page of an asmx file is placed into the app_code folder.
aspx	1.0	An ASP.NET Web Forms page that can contain Web controls and presentation and business logic. http://msdn.microsoft.com/en-us/library/2wawkw1c.aspx
axd	1.0	when enabled in web.config requesting trace.axd outputs application-level tracing. Also used for the special webresource.axd handler which allows control/component developers to package a component/control complete with images, script, css etc. for deployment in one file (an 'assembly')
browser	2.0	browser capabilities files stored in XML format; introduced in version 2.0. ASP.NET 2 includes many of these by default, to support common Web browsers. These specify which browsers have which abilities, so that ASP.NET 2 can automatically customize and optimize its output accordingly. Special .browser files are available for free download to handle, for instance, the W3C Validator, so that it properly shows standards-compliant pages as being standards-compliant. Replaces the harder-to-use BrowserCaps section that was in machine.config and could be overridden in web.config in ASP.NET 1.x.
config	1.0	web.config is the only file in a specific Web application to use this extension by default (machine.config similarly affects the entire Web server and all applications on it), however ASP.NET provides facilities to create and consume other config files. These are stored in XML format.
cs/vb	1.0	Code files (cs indicates C#, vb indicates Visual Basic, fs indicates F#). Code behind files (see above) predominantly have the extension ".aspx.cs" or ".aspx.vb" for the two most common languages. Other code files (often containing common "library" classes) can also exist in the Web folders with the cs/vb extension. In ASP.NET 2 these should be placed inside the App_Code folder where they are dynamically compiled and available to the whole application.
cshtml	4.1	Views (mixed C# and HTML using Razor syntax)
dbml	3.5	LINQ to SQL data classes file
edmx	3.5	ADO.NET Entity Framework model
master	2.0	master page file. Default file name is Master1.master
resx	1.0	resource files for internationalization and localization. Resource files can be global (e.g. messages) or "local" which means specific for one aspx or ascx file.
sitemap	2.0	Sitemap configuration files. Default file name is web. Sitemap
skin	2.0	theme skin files.
svc	3.0	Windows Communication Foundation service file
vbhtml	4.1	Views (mixed VB and HTML using Razor syntax)

Directory structure

In general, the ASP.NET directory structure can be determined by the developer's preferences. Apart from a few reserved directory names, the site can span any number of directories. The structure is typically reflected directly in the URLs. Although ASP.NET provides means for intercepting the request at any point during processing, the developer is not forced to funnel requests through a central application or front controller.

The special directory names (from ASP.NET 2.0 on) are:

App_Code 
This is the "raw code" directory. The ASP.NET server automatically compiles files (and subdirectories) in this folder into an assembly which is accessible in the code of every page of the site. App_Code will typically be used for data access abstraction code, model code and business code. Also any site-specific http handlers and modules and Web service implementation go in this directory. As an alternative to using App_Code the developer may opt to provide a separate assembly with precompiled code.


App_Data 
The App_Data ASP.NET Directory is the default directory for any database used by the ASP.NET Website. These databases might include Access (mdb) files or SQL Server (mdf) files. The App_Data is the only directory with Write Access enabled for the ASP.NET web application.


App_LocalResources
E.g. a file called CheckOut.aspx.fr-FR.resx holds localized resources for the French version of the CheckOut.aspx page. When the UI culture is set to French, ASP.NET will automatically find and use this file for localization.


App_GlobalResources 
Holds resx files with localized resources available to every page of the site. This is where the ASP.NET developer will typically store localized messages etc. which are used on more than one page.


App_Themes 
Adds a folder that holds files related to themes which are a new ASP.NET feature that helps ensure a consistent appearance throughout a Web site and makes it easier to change the Web site’s appearance when necessary.


App_WebReferences 
holds discovery files and WSDL files for references to Web services to be consumed in the site.


Bin 
Contains compiled code (.dll files) for controls, components, or other code that you want to reference in your application. Any classes represented by code in the Bin folder are automatically referenced in your application.

Performance

ASP.NET aims for performance benefits over other script-based technologies (including Classic ASP) by compiling the server-side code to one or more DLL files on the Web server. This compilation happens automatically the first time a page is requested (which means the developer need not perform a separate compilation step for pages). This feature provides the ease of development offered by scripting languages with the performance benefits of a compiled binary. However, the compilation might cause a noticeable but short delay to the Web user when the newly-edited page is first requested from the Web server, but will not again unless the page requested is updated further.


The ASPX and other resource files are placed in a virtual host on an Internet Information Services server (or other compatible ASP.NET servers; see Other implementations, below). The first time a client requests a page, the .NET Framework parses and compiles the file(s) into a .NET assembly and sends the response; subsequent requests are served from the DLL files. By default ASP.NET will compile the entire site in batches of 1000 files upon first request. If the compilation delay is causing problems, the batch size or the compilation strategy may be tweaked.


Developers can also choose to pre-compile their "codebehind" files before deployment, using MS Visual Studio, eliminating the need for just-in-time compilation in a production environment. This also eliminates the need of having the source code on the Web server. It also supports pre-compile text.

Extension

Microsoft has released some extension frameworks that plug into ASP.NET and extend its functionality. Some of them are:
ASP.NET AJAX:  An extension with both client-sides as well as server-side components for writing ASP.NET pages that incorporate AJAX functionality.
ASP.NET MVC Framework: An extension to author ASP.NET pages using the MVC architecture.

Development tools

Several available software packages exist for developing ASP.NET applications:

Software	Developer	Licensing
ASP.NET Intellisense Generator [2]	BlueVision LLC	Free
Microsoft Visual Studio	Microsoft	Free and commercial
Microsoft Visual Web Developer Express	Microsoft	Registerware
CodeGear Delphi	Embarcadero Technologies	Commercial
Macromedia HomeSite	Adobe Systems	Commercial
Microsoft Expression Web	Microsoft	Commercial
Microsoft SharePoint Designer	Microsoft	Free
MonoDevelop	Novell and the Mono community	Free open source
SharpDevelop	ICSharpCode Team	Free open source
Eiffel for ASP.NET [3]	Eiffel Software	Free open source and commercial
Adobe Dreamweaver	Adobe Systems	Commercial

Reference:

http://en.wikipedia.org/wiki/ASP.NET