There are three places in ASP.NET to define what happens to these unhandled errors.
The global.asax file contains the next line of defense against errors. When an error occurs, the Application_Error sub is called. This location happens to be my favorite place to log errors because it is the most functional. For most of my applications in .NET, I don't handle too many custom errors at the page level. I handle them at the application level. The only two locations that actually give you access to Server.GetLastError are in the Page_Error and Application_Error subs.
After the Page_Error is called, the Application_Error sub is called. Here you can also log the error and redirect to another page. I won't explain anything else about it because it is basically the same as the Page_Error but happens to be at the application level rather than the page level.
Using the web.config File
The customErrors element of the web.config file is the last line of defense against an unhandled error. If you have other error handlers in place, like the Application_Error of Page_Error subs, these will get called first. Provided they don't do a Response.Redirect or a Server.ClearError, you should be brought to the page(s) defined in the web.config. In the web.config file, you can handle specific error codes (500, 404, etc), or you can use one page to handle all errors. This is a major difference between this method and the others (although you can emulate this by doing various Response.Redirects using the other methods). Open up your web.config file. The customErrors section uses this format:
<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">
<error statusCode="statuscode" redirect="url"/>
</customErrors>
Here is some important information about the "mode" attribute:
"On" specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.
"Off" specifies that custom errors are disabled. This allows display of detailed errors.
"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.
By default, the section looks like this when you create a Web application.
- In the web.config file's customErrors section.
- In the global.asax file's Application_Error sub.
- On the aspx or associated codebehind page in the Page_Error sub.
- On the Page itself, in the Page_Error sub
- The global.asax Application_Error sub
- The web.config
- HelpLink : Gets or sets a link to the help file associated with this exception.
- InnerException : Gets the Exception instance that caused the current exception.
- Message : Gets a message that describes the current exception.
- Source : Gets or sets the name of the application or the object that causes the error.
- StackTrace : Gets a string representation of the frames on the call stack at the time the current exception was thrown.
- TargetSite : Gets the method that throws the current exception.
The global.asax file contains the next line of defense against errors. When an error occurs, the Application_Error sub is called. This location happens to be my favorite place to log errors because it is the most functional. For most of my applications in .NET, I don't handle too many custom errors at the page level. I handle them at the application level. The only two locations that actually give you access to Server.GetLastError are in the Page_Error and Application_Error subs.
After the Page_Error is called, the Application_Error sub is called. Here you can also log the error and redirect to another page. I won't explain anything else about it because it is basically the same as the Page_Error but happens to be at the application level rather than the page level.
Using the web.config File
The customErrors element of the web.config file is the last line of defense against an unhandled error. If you have other error handlers in place, like the Application_Error of Page_Error subs, these will get called first. Provided they don't do a Response.Redirect or a Server.ClearError, you should be brought to the page(s) defined in the web.config. In the web.config file, you can handle specific error codes (500, 404, etc), or you can use one page to handle all errors. This is a major difference between this method and the others (although you can emulate this by doing various Response.Redirects using the other methods). Open up your web.config file. The customErrors section uses this format:
<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">
<error statusCode="statuscode" redirect="url"/>
</customErrors>
Here is some important information about the "mode" attribute:
"On" specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.
"Off" specifies that custom errors are disabled. This allows display of detailed errors.
"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.
By default, the section looks like this when you create a Web application.
When the site goes live change the debug setting to false which will make the site have a little better performance.
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session 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. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To 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:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
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 stored.
The 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.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>
<compilation defaultLanguage="C#" debug="true" />
Customer errors can be handled be turned off but I prefer them to be turned on as below.
<customErrors mode="Off" />
You can also do per page tracing so that you can turn off application Tracing and have trace="true" at the top of a single page.
<trace enabled="true" requestLimit="10" pageOutput="true" traceMode="SortByTime" localOnly="true"/>
ASP.NET provides a configuration system we can use to keep our applications flexible at runtime. In this article we will examine some tips and best practices for using the configuration system for the best results.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
</configuration>
Multiple File Configuration
The appSettings element may contain a file attribute that points to an external file. Let’s change our web.config to look like the following
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings file="dbsettings.config"/>
</configuration>
Next, we can create the external file ‘dbsettings.config’ and add an appSettings section with our connection information.
<appSettings>
<add key="ConnectionInfo" value="server=(local);database=Northwind;Integrated Security=SSPI" />
</appSettings>
If the external file is present, ASP.NET will combine the appSettings values from web.config with those in the external file. If a key/value pair is present in both files, ASP.NET will use the value from the external file.
Session States:
Session 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. Asp .net stores the sessions in different ways. By default the session is stored in the asp .net process. You can always configure the application so that the session will be stored in one of the following ways
[1] Session State Service
There are two main advantages of using the State Service. First the state service is not running in the same process as the asp .net application. So even if the asp .net application crashes the sessions will not be destroyed. Any advantage is sharing the state information across a Web garden (Multiple processors for the same computer).
Lets see a example of the Session State Service.
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:55455" sqlConnectionString="data source=127.0.0.1;user id=sa;password='' cookieless="false" timeout="20"/>
The attributes are self explanatory but I will go over them.
mode: This can be StateServer or SqlServer. Since we are using StateServer we set the mode to StateServer.
stateConnectionString: connectionString that is used to locate the State Service.
sqlConnectionString: The connection String of the sql server database.
cookieless: Cookieless equal to false means that we will be using cookies to store the session on the client side.
[2.] SQL Server
The final choice to save the session information is using the Sql Server 2000 database. To 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:
<sessionState mode = "SqlServer" stateConnectionString="tcpip=127.0.0.1:45565" sqlConnectionString="data source="SERVERNAME;user id=sa;password='' cookiesless="false" timeout="20"/>
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 stored.
The 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.
[3] InProc:
This is another Session State. This one is mostly used for development purposes. The biggest advantage of using this approach is the applications will run faster when compared to other Session state types. But the disadvantage is Sessions are not stored when there is any problem that occurs with the application, when there is a small change in the files etc., Also there could be frequent loss of session data experienced.
Error Handling:
<customErrors mode = "On">
<error statusCode = "404" redirect = "errorPage.aspx" />
</customErrors>
Security:
The most critical aspect of any application is the security. Asp.net offers many different types of security method which can be used depending upon the condition and type of security you need.
[1] No Authentication:
No Authentication means "No Authentication" :) , meaning that Asp.net will not implement any type of security.
[2] Windows Authentication:
The Windows authentication allows us to use the windows user accounts. This provider uses IIS to perform the actual authentication, and then passes the authenticated identity to your code. If you like to see that what windows user is using the Asp.net application you can use:
User.Identity.Name;
This returns the DOMAIN\UserName of the current user of the local machine.
[3] Passport Authentication:
Passport Authentication provider uses Microsoft's Passport service to authenticate users.
[4] Forms Authentication:
Forms Authentication uses HTML forms to collect the user information and than it takes required actions on those HTML collected values.
In order to use Forms Authentication you must set the Anonymous Access checkbox checked. Now we need that whenever user tries to run the application he/she will be redirected to the login page.
<authentication mode="Forms">
<forms loginUrl = "frmLogin.aspx" name="FAutho" timeout="1"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>