20
Configuration Files in ASP .NET
Configuration Files inASP .NET
Three Important Configuration Files in ASP .NET are
Web.ConfigMachine.ConfigGlobal.asax
Web.ConfigWeb.config file, as it sounds like is a configuration file for the Asp .net Web ApplicationAn Asp .net application has one web.config file which keeps the configurations required for the corresponding applicationWeb.config file is written in XML with specific tagshaving specific meaningsWhat can be stored in Web.configfile?There are number of important settings that can be stored in the configuration file. Here are some of the most frequently used configurations, stored conveniently inside Web.config fileDatabase Connections Session States Error Handling Security
Database ConnectionsThe most important configuration data that can be stored inside the web.config file is the databaseconnection string Storing the connection string in the web.config file makes sense, since any modifications to the database configurations can be maintained at a single locationAs otherwise we'll have to keep it either as a class level variable in all the associated source files or probably keep it in another class as a public static variable
As you can see it is really simple to store the connection string in the web.config file The connection string is referenced by a name which in this case is " DBPersonStringThe ConnectionString attribute of the configuration file denotes the information about the database. Here we can see that if has database name, userid and passwordLets see how we access the connection string from our Asp .net web application
using System.Configuration;
string connString = ConfigurationManager.ConnectionStrings[DBPersonString].ConnectionString
Session StateA session is defined as the period of time that a unique user interacts with a Web application. Session state is a collection of objects, tied to a session are stored on a serverASP.NET Session StateASP.NET session state solves problems associated with classic ASP session stateProcess independent. ASP.NET session state is able to run in a separate process from the ASP.NET host process. If session state is in a separate process, the ASP.NET process can come and go while the session state process remains availableSupport for server farm configurations. By moving to an out-of-process model, ASP.NET also solves the server farm problem. The new out-of-process model allows all servers in the farm to share a session state process. You can implement this by changing the ASP.NET configuration to point to a common serverCookie independent. Although solutions to the problem of cookieless state management do exist for classic ASP, they're not trivial to implement. ASP.NET, on the other hand, reduces the complexities of cookieless session state to a simple configuration setting
Session configurationSession in Asp .net web application is very important. As we know that HTTP is a stateless protocol and we needs session to keep the state alive Below is a sample web.config file used to configure the session state settings for an ASP.NET application
Mode. The mode setting supports three options: inproc, sqlserver, and stateserver. As stated earlier, ASP.NET supports two modes: in process and out of process. There are also two options for out-of-process state management: memory based (stateserver), and SQL Server based (sqlserver). We'll discuss implementing these options shortly. Cookieless. The cookieless option for ASP.NET is configured with this simple Boolean setting. Timeout. This option controls the length of time a session is considered valid. The session timeout is a sliding value; on each request the timeout period is set to the current time plus the timeout value Sqlconnectionstring. The sqlconnectionstring identifies the database connection string that names the database used for mode sqlserver. Server. In the out-of-process mode stateserver, it names the server that is running the required Windows NT service: ASPState. Port. The port setting, which accompanies the server setting, identifies the port number that corresponds to the server setting for mode stateserver
AttributeOptionDescriptionmodeSpecifies where to store the session state OffDisables session state management InProcSession state is stored locally in memory of ASP.NET worker processStateServerSession state is stored outside ASP.NET worker process and is managed by Windows service. Location of this service is specified by stateConnectionString attribute SQLServerSession state is stored outside ASP.NET worker process in SQL Server database. Location of this database is represented by sqlConnectionString attribute
In-process ModeIn-process mode simply means using ASP.NET session state in a similar manner to classic ASP session state. That is, session state is managed in process and if the process is re-cycled, state is lost. Given the new settings that ASP.NET provides, you might wonder why you would ever use this mode. The reasoning is quite simple: performance. The performance of session state, e.g. the time it takes to read from and write to the session state dictionary, will be much faster when the memory read to and from is in process, as cross-process calls add overhead when data is marshaled back and forth or possibly read from SQL Server.In-process mode is the default setting for ASP.NET. When this setting is used, the only other session web. config settings used are cookieless and timeout.
SQL ServerTo use Sql Server for storing session state you need to do the following:Run the InstallSqlState.sql script on the Microsoft SQL Server where you intend to store the session.You web.config settings will look something like this:SQL Server lets you share session state among the processors in a Web garden or the servers in a Web farm. Apart from that you also get additional space to store the session. And after that you can take various actions on the session storedThe downside is SQL Server is slow as compared to storing session in the state in process. And also SQL Server cost too much for a small company
Error HandlingWhen errors occur in an ASP.NET application, they either get handled or propagates unhandled to higher scopesWhen an unhandled exception propagates, the user may be redirected to an error page using different ASP.NET configuration settingsThere are two different scopes where we could specify which page the user should be redirected to, when errors go unhandled:Page level (applies to errors that happen within a single page)Application level (applies to errors that happen anywhere in the application)Page LevelUse the errorPage attribute in the webform
Application LevelUse the customErrors section in web.config
Machine.ConfigAs web.config file is used to configure one asp .net web application, same way Machine.config file is used to configure the application according to a particular machineThat is, configuration done in machine.config file is affected on any application that runs on a particular machineUsually, this file is not altered and only web.config is used which configuring applications It is present in the locationC:\WINDOWS\Microsoft.NET\Framework\\CONFIG
Global.asaxThe Global.asax file, sometimes called the ASP.NET application file, provides a way to respond to application or module level events in one central location. You can use this file to implement application security, as well as other tasksGlobal.asax is a file that resides in the root directory of your applicationIt is inaccessible over the web but is used by the ASP.NET application if it is thereIt is a collection of event handlers that you can use to change and set settings in your siteThe events can come from one of two places - The HTTPApplication object and any HTTPModule object that is specified in web.confg or machine.config. We will be covering both here
Exposed EventsApplication_Init: Fired when an application initializes or is first called. It's invoked for all HttpApplication object instances. Application_Disposed: Fired just before an application is destroyed. This is the ideal location for cleaning up previously used resources. Application_Error: Fired when an unhandled exception is encountered within the application. Application_Start: Fired when the first instance of the HttpApplication class is created. It allows you to create objects that are accessible by all HttpApplication instances. Application_End: Fired when the last instance of an HttpApplication class is destroyed. It's fired only once during an application's lifetime. Application_BeginRequest: Fired when an application request is received. It's the first event fired for a request, which is often a page request (URL) that a user enters. Application_EndRequest: The last event fired for an application request. Application_PreRequestHandlerExecute: Fired before the ASP.NET page framework begins executing an event handler like a page or Web service.
Exposed EventsApplication_PostRequestHandlerExecute: Fired when the ASP.NET page framework is finished executing an event handler. Applcation_PreSendRequestHeaders: Fired before the ASP.NET page framework sends HTTP headers to a requesting client (browser). Application_PreSendContent: Fired before the ASP.NET page framework sends content to a requesting client (browser). Application_AcquireRequestState: Fired when the ASP.NET page framework gets the current state (Session state) related to the current request. Application_ReleaseRequestState: Fired when the ASP.NET page framework completes execution of all event handlers. This results in all state modules to save their current state data.Application_ResolveRequestCache: Fired when the ASP.NET page framework completes an authorization request. It allows caching modules to serve the request from the cache, thus bypassing handler execution.
Exposed EventsApplication_UpdateRequestCache: Fired when the ASP.NET page framework completes handler execution to allow caching modules to store responses to be used to handle subsequent requests. Application_AuthenticateRequest: Fired when the security module has established the current user's identity as valid. At this point, the user's credentials have been validated. Application_AuthorizeRequest: Fired when the security module has verified that a user can access resources. Session_Start: Fired when a new user visits the application Web site. Session_End: Fired when a user's session times out, ends, or they leave the application Web site.
THANK YOU
