ASP.NET Configuration Files

The Microsoft® ASP.NET configuration system features an extensible infrastructure that enables you to define configuration settings when your ASP.NET applications are first deployed so that you can add or revise configuration settings at any time with minimal impact on operational Web applications and servers.


The ASP.NET configuration system provides the following benefits:

Configuration information is stored in XML-based text files. You can use any standard text editor or XML parser to create and edit ASP.NET configuration files.

ASP.NET allows configuration settings to be stored together with static content, dynamic pages, and business objects within a single application directory hierarchy. A user or administrator simply needs to copy a single directory tree to set up an ASP.NET Framework application on a machine

Configuration data is stored in plain text files that are both human-readable and human-writable. Administrators and developers can use any standard text editor, XML parser, or scripting language to interpret and update configuration settings.

Multiple configuration files, all named Web.config, can appear in multiple directories on an ASP.NET Application server. Each Web.config file applies configuration settings to its own directory and all child directories below it. Configuration files in child directories can supply configuration information in addition to that inherited from parent directories, and the child directory configuration settings can override or modify settings defined in parent directories. The root configuration file named systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\Machine.config provides ASP.NET configuration settings for the entire Web server.

At run time, ASP.NET uses the configuration information provided by the Web.config files in a hierarchical virtual directory structure to compute a collection of configuration settings for each unique URL resource. The resulting configuration settings are then cached for all subsequent requests to a resource. Note that inheritance is defined by the incoming request path (the URL), not the file system paths to the resources on disk (the physical paths).

ASP.NET provides an extensible configuration infrastructure that enables third-party developers to store their own configuration settings, define the persistence format of their own configuration settings, intelligently participate in their processing, and control the resulting object model through which those settings are ultimately exposed.

Changes to ASP.NET configuration files are automatically detected by the system and are applied without requiring any user intervention (in other words, an administrator does not need to restart the Web server or reboot the machine for them to take effect).

The ASP.NET configuration system is extensible. You can define new configuration parameters and write configuration section handlers to process them.

ASP.NET helps protect configuration files from outside access by configuring Internet Information Services (IIS) to help prevent direct browser access to configuration files. HTTP access error 403 (forbidden) is returned to any browser attempting to request a configuration file directly.

ASP.NET Page Life Cycle

A page in an ASP.NET application consists of several server controls. These are the fundamental building blocks of an ASP.NET application. The Life cycle of an ASP.NET page, depends on whether the page is requested for the first time or it is a postback. Postback is a process by which a page can request for itself.

When the Page is requested for the first time


The Life Cycle of a page when requested for the first time:

Initializing: During this phase, the server creates an instance of the server control

Loading: During this phase, the instance of the control is loaded onto the page object in which it is defined.

PreRendering: During this phase, the control is updated with the changes made to it. This prepares the control for rendering.

Saving: During this phase, the state information of the control is saved. For example, if a value is set for the control during the Load event, it is embedded in the HTML tag that will be returned to the browser.

Rendering: During this phase, the server creates the corresponding HTML tag for the control.

Disposing: During this phase, all cleanup tasks, such as closing files and database connections opened by the control are performed.

Unloading: During this phase, all cleanup tasks, such as destroying the instances of server control are performed. This is the final event in the life cycle of a server control

Life cycle when the page processed during a postback event
The processing sequence in which a page is processed during a postback event is:

Initializing: During this phase, the server creates an instance of the server control

Loading view state: During this phase, the view state of the control posted by the client is reloaded into the new instance of the control.

Loading: During this phase, the instance of the control is loaded onto the page object in which it is defined.

Loading the postback data: During this phase, the server searches any data corresponding to the control that is loaded in the data posted by the client.

PreRendering: During this phase, the control is updated with the changes made to it. This prepares the control for rendering.

Saving state: During this phase, the change in the state of control between the current request and the previous request of the page is saved. For each change, the corresponding event is raised. For example, if the text of a textbox is changed, the new text is saved and a text_change event is raised.

Rendering: During this phase, the server creates the corresponding HTML tag for the control.

Disposing: During this phase, all cleanup tasks, such as closing files and database connections opened by the control are performed.

Unloading: During this phase, all cleanup tasks, such as destroying the instances of server control are performed. This is the final event in the life cycle of a server control

The events associated with the relevant page cycle phases are:

Page Initialization: Page_Init

View State Loading:LoadViewState

Postback data processing: LoadPostData

Page Loading: Page_Load

PostBack Change Notification: RaisePostDataChangedEvent

PostBack Event Handling: RaisePostBackEvent

Page Pre Rendering Phase: Page_PreRender

View State Saving: SaveViewState

Page Rendering: Page_Render

Page Unloading: Page_UnLoad

The following figure illustrates how the server controls on an ASP.NET page is processed by the server:

The ADO.NET Architecture

Data Access in ADO.NET relies on two components: DataSet and Data Provider.

DataSet

The dataset is a disconnected, in-memory representation of data. It can be considered as a local copy of the relevant portions of the database. The DataSet is persisted in memory and the data in it can be manipulated and updated independent of the database. When the use of this DataSet is finished, changes can be made back to the central database for updating. The data in DataSet can be loaded from any valid data source like Microsoft SQL server database, an Oracle database or from a Microsoft Access database.

Data Provider

The Data Provider is responsible for providing and maintaining the connection to the database. A DataProvider is a set of related components that work together to provide data in an efficient and performance driven manner. The .NET Framework currently comes with two DataProviders: the SQL Data Provider which is designed only to work with Microsoft's SQL Server 7.0 or later and the OleDb DataProvider which allows us to connect to other types of databases like Access and Oracle. Each DataProvider consists of the following component classes:

The Connection object which provides a connection to the database
The Command object which is used to execute a command
The DataReader object which provides a forward-only, read only, connected recordset
The DataAdapter object which populates a disconnected DataSet with data and performs update

ADO.Net Overview

Most applications need data access at one point of time making it a crucial component when working with applications. Data access is making the application interact with a database, where all the data is stored. Different applications have different requirements for database access. VB .NET uses ADO .NET (Active X Data Object) as it's data access and manipulation protocol which also enables us to work with data on the Internet. Let's take a look why ADO .NET came into picture replacing ADO


ADO.NET provides consistent access to data sources such as Microsoft SQL Server, as well as data sources exposed through OLE DB and XML. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, manipulate, and update data.

ADO.NET cleanly factors data access from data manipulation into discrete components that can be used separately or in tandem. ADO.NET includes .NET Framework data providers for connecting to a database, executing commands, and retrieving results. Those results are either processed directly, or placed in an ADO.NET DataSet object in order to be exposed to the user in an ad-hoc manner, combined with data from multiple sources, or remoted between tiers. The ADO.NET DataSet object can also be used independently of a .NET Framework data provider to manage data local to the application or sourced from XML.

ASP.Net State Managment

Application

Application object was generally used when some data was to be stored which all users could use. The size of the data was not really a constraint since there would be only a single copy of that data. The data would be stored for the life of the application. In ASP 3.0, the Application object was generally used to store pieces of data that changed rarely such as contents of menu or Database connection strings (mainly read only data).
In ASP.NET, such configuration data as database connection strings are best stored in config files. One thing to consider if you are using the Application object is that any writes to it should be done either in its Application_OnStart event (in global.asax). Since the config files are XML files, they can be changed whenever required.

Session
Session data is valid only for a particular user session. The size of data is again not a constraint, but it is to be kept to a minimum to make the application more scalable.
The major disadvantages with Session was that it uses cookies and in ASP 3.0, it tied the user to one particular Web Server since session data could not shared in Web farms or a clustered environment. With ASP.NET, storing sessions on an external state server or a database for managing session data.
Even then, Session object is inefficient way to store data since the data is still stored in memory even after the user has stopped using the site. This can affect the scalability on busy web sites. The Cache object allows more control on release of memory and is more suited for large data values. However, For small amounts of data, the Session object can be a perfectly valid place to store user-specific data that needs to persist only for the duration of the user's current session.
Even when not in use, sessions carry some overhead for an application. Performance can be enhanced if session is turned off on pages, which don’t use them. Also, setting session state to read-only can also optimize pages that read but do not write data to sessions.

Cookies
The biggest advantage of cookies is that the data can be persisted for a variable amount of time. The data can be persisted with for the life of the browser window or if required, for months or years. Cookies are generally very small since they are maintained on the client and have to be transferred to the server whenever that data is required. Hence the contents should be as less as possible. It is a powerful way to maintain state even in clustered environment or a web farm, which is the reason why most web sites on the net use them.
Cookies are small text files kept on the client machine which can be easily deleted by the user plus the contents are not encrypted, hence sensitive information should never be stored in cookies.
Hidden Form Fields
Hidden Form fields sent with the posting of form to the server is generally used to store user specific data. The size of the data is not a constraint. This technique was used more often than not in ASP 3.0, but now made redundant by the new techniques introduced in ASP.NET like Web Controls and ViewState. These techniques are discussed further.
QueryString
QueryStrings like hidden form fields are user specific data. Its lifecycle can be as brief as a single request or it can be maintained through out the application. The size of the data is a major constraint, it cannot be more than 1K. Another major constraint is that, since the data is passed with the URL , the data is visible to the user and hence no sensitive information is stored in QueryStrings unless it is encrypted to remove human-readability. Also, Server.UrlEncode should be used to encode characters that are not valid in URLs. However, they still continue to be a very good alternative to pass information between page requests. DataGrids, which is a ASP.NET web control uses querystrings in it’s hyperlink columns.
For long-term data storage, Cookie, Session, or Cache are more appropriate options than QueryStrings.

New State Management techniques with ASP.NET

Cache
Cache data is specific to the single user, a subset of users, or even all users. This data persists for multiple requests. It can persist for a long time, but not across application restarts. Also, data can expire based on time or other dependencies. It can hold both large and small amounts of data effectively.
It offers incredible flexibility, versatility, and performance, and is therefore often a better choice than Application or Session for persisting data within an ASP.NET application. It is simply a name-value collection, but by using a key value that is specific to a user, you can make the cached values user-specific. The data in the Cache can be given an expiration period that is absolute, sliding, or based on changes to a file. One of the more powerful features of the Cache object is its ability to execute a callback when an item in the cache expires.
The Cache object has a lot more functionality than most of the other objects.

Context
The Context object holds data for a single user, for a single request, and it is only persisted for the duration of the request. The Context container can hold large amounts of data, but typically it is used to hold small pieces of data because it is often implemented for every request through a handler in the global.asax.

ViewState
ViewState is again a user specific technique and is valid for a particular ASPX page. It can hold any amount of data but it should be kept to the minimum it adds to the size of end HTML to the client browser.
Web Controls use View State to automatically maintain state between requests to the same page. The size of the ViewState can be seen by viewing the source of the page and checking for the hidden form field “__VIEWSTATE”. By default, the ViewState is turned ON, so it should be turned OFF for all web controls, that don’t need their data to be persisted across requests. ViewState can also be disabled for an entire page by adding EnableViewState="false" to the @Page directive.

Web.config and Machine.config Files
These files are basically XML files. The data in these files is common for the entire application, which is available for the entire life of the application. The size of the data is usually limited. Configuration settings are best kept in these files. Each ASP.NET application uses a Web.config file to set many of its properties, and each server has a Machine.config file located in its system folder that is used as a basis for all applications. These settings are used as defaults unless overridden. Configuration information is read whenever the application starts, and is then cached. Since it is cached, the application can read this data very quickly, so you should not be concerned that your application will have a bottleneck because it has to constantly refer to a text file for some integral information. Any changes to the config files are reflected only on application restart. Database connection information, default image paths, and paths to XML data files are some of the more common pieces of data that are stored in the Web.config file.

Advantages of ASP.NET

1. Separation of Code from HTMLTo make a clean sweep, with ASP.NET you have the ability to completely separate layout and business logic. This makes it much easier for teams of programmers and designers to collaborate efficiently. This makes it much easier for teams of programmers and designers to collaborate efficiently.
2. Support for compiled languagesdeveloper can use VB.NET and access features such as strong typing and object-oriented programming. Using compiled languages also means that ASP.NET pages do not suffer the performance penalties associated with interpreted code. ASP.NET pages are precompiled to byte-code and Just In Time (JIT) compiled when first requested. Subsequent requests are directed to the fully compiled code, which is cached until the source changes.
3. Use services provided by the .NET FrameworkThe .NET Framework provides class libraries that can be used by your application. Some of the key classes help you with input/output, access to operating system services, data access, or even debugging. We will go into more detail on some of them in this module.
4. Graphical Development EnvironmentVisual Studio .NET provides a very rich development environment for Webdevelopers. You can drag and drop controls and set properties the way you do in Visual Basic 6. And you have full IntelliSense support, not only for your code, but also for HTML and XML.
5. State managementTo refer to the problems mentioned before, ASP.NET provides solutions for session and application state management. State information can, for example, be kept in memory or stored in a database. It can be shared across Web farms, and state information can be recovered, even if the server fails or the connection breaks down.
6. Update files while the server is running!Components of your application can be updated while the server is online and clients are connected. The Framework will use the new files as soon as they are copied to the application. Removed or old files that are still in use are kept in memory until the clients have finished.
7. XML-Based Configuration FilesConfiguration settings in ASP.NET are stored in XML files that you can easily read and edit. You can also easily copy these to another server, along with the other files that comprise your application.

What is Microsoft.NET platform?

Microsoft .NET is a software development platform based on virtual machine based architecture. Dot net is designed from the scratch to support programming language independent application development. The entire .NET programs are independent of any particular operating system and physical hardware machine. They can run on any physical machine, running any operating system that contains the implementation of .NET Framework. The core component of the .NET framework is its Common Language Runtime (CLR), which provides the abstraction of execution environment (Physical machine and Operating System) and manages the overall execution of any of the .NET based program.