Errors – Suraj | Coding Passion

The Unsung Hero ELMAH-Part 2

Suraj Sahoo — Sat, 07 Feb 2015 19:17:36 +0000

Background

As discussed in my prvious blog post i.e. ELMAH Part-1.
Now in this article I will be explaining the integration of ELMAH with Sql Server(SSMS). This is now-a-days an essential part in any application, that is error and exceptions that rise in the application are logged into the database tables that are related to ELMAH. These table scripts are providedby ELMAH itself. Dont Believe!! I also did not. But that is the truth. Lets see and discuss now..

ELMAH Configuration

Here I am specifying all the requirements for setting up ELMAH in the web.config settings. As the installationand also the setting have been explained in Part-1. Still I am specifying the blocks required in the Web.Config.

Inside the System.webServer block:


      
      
    Snippet

 <handlers>
      <add name="Elmah" verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
    </handlers>

above are the modules and handlers as well.

Inside system.Web:

The above are the common settings for the ELMAH. Now lets look into the settings required for database settings.

As we all have an access and look at the connection strings. Still lets have a quick look:

The above is the pattern of the connection strings. Donot use the same one..just kidding..

Then the final change for the ELMAH with the Sql :


    
    [email protected]" to="[email protected]" subject="DEMO Error" async="false" useSsl="true" />

This was the final change required for the web.config change to integrate ELMAH with SSMS.

Queries for ELMAH

Now, let me reveal the magic to you as I mentioned earlier. Yes guys, queries we donot have to write , ready-made queries are provided by the ELMAH team. The download link for the ELMAH Queries is :-Queries for ELMAH

Just simply download the “.sql” file and run in the SSMS. After execution the tables get created for the ELMAH as well as the stored procedures shown below:

As you can see above, the tables and stored procedures are added into the database. This is so simple and as simple it can be. Is’nt this great!!

Lets see the number of columns and what columns are being created in the table dbo.ELMAH_Error

Then every exceptions rising will be added into the table and can be easily used by developers for future reference.

I hope this helps developers anyway. This article covers all the setting configurations required.
Thus the setup is as simple as it can be. Thanks to Andy French.

The Unsung Hero “ELMAH”

Suraj Sahoo — Fri, 06 Feb 2015 21:01:28 +0000

Introduction

ELMAH, Error Logging Modules & Handlers is a tool for debugging mainly ASP.NET applications suggested by wiki. As we all know there is always a chance of getting exceptions while working on any applications. Handling them is a real challenge for many developers. But if we have a tool, that gives us the details of the exceptions or errors with the stack trace as well. Apart from showing the users the yellow screen of death, we show the users a customized error page, but for the developers if any exceptions occur instead of having a try catch block at every method, ELMAH provides them the details of the exceptions with the entire stack trace and solve the issue based on the error code. For more information on error codes and redirect please follow one of my other articles Custom Errors. Lets get into more details how this beautiful tool works.

What we get?

You would be wondering what this ELMAH gives us after adding this into the application? Straight from the Hanselmen’s blog, ELMAH would give us the following without changing a single peice of code. Since the ELMAH includes Modules and Handlers, it greatly supports HttpModules and Http Handlers.

All unhandled exceptions(Null reference, Out of bound exception, etc.) are logged in the ELMAH interface
A webpage can remotely view the logged detailed exceptions
Since this shows the entire stack trace, the so called yellow screen of death can also be seen but in the ELMAH interface
ELMAH also gives an opportunity to store the exceptions or log them into tables (SSMS).

When suppose the above is the case, then the user using the application, lands on the above redirect path url pages, where as the error and exception are managed by ELMAH and mailed or logged into the database for future reference for the developers.

Installation for an existing MVC project

Step 1: Go to references and right click on the Manage Nuget Packages

Step 2: Search online for Elmah.MVC

Step 3: After the succesful installation, you can check the package.config for the version of elmah installed shown below:

Step 4: You need to ensure then the below web.config configurations as shown in the images below:


    // To allow remote access

Now everything is set for developers to check for the internal exceptions occured. But how to access the ELMAH interface? It is simple, just use the path url succeding with /elmah.axd then done you see the list of exceptions/errors occured. The interface would look like below image:

Integration of ELMAH to GMAIL

Yes guys you heard h=it right as the heading says, we can integrate email settings into the ELMAH and send the entire stack trace and exception details as mail to multiple users using a subject too.

Below I would be discussing the integration and set up for the mail settings. here I use the Gmail setting. The best part here is the change is only done at the web.config level. Below are the proper configurations.

First in the system.webServer/modules section add the below peice of line. The final module is below:
```
      
      
    
```
Then after adding this module section, we need a set up for the Gmail in the system.net/mailSettings section as below:
```
    
      [email protected]">
        
      
    
  
```
Just remember you need to set your gmail username and password. Google Mail is very smart and doesnot simply ets the mail come or the application to sign in into the gmail, as that may be from an unauthenticated source. To avoid this, you need to follow the mail which Google will send you and you need to approve that you want that Ip source to use your mail settings to send mail. Thus, you make google happy.
Then finally we need to set the elmah section with the following block:
```
    
    [email protected]" to="[email protected]" subject="DEMO Error" async="false" useSsl="true" />
  
```
Thus, all set now our application/ELMAH is smart enough to understand the configurations and send mails to the specified users. Remember in the above block “to”, you can specify more than one mail addresses separated by comma. Thus, have a look at the image below to see how the mail looks like:
The above is a part of how the mail looks like.

Thus, we have discussed everything related to ELMAH. In the upcoming article/blog I will be explaining how to store into tables using connection strings. The interaction of Sql server of ELMAH.

References

Scott Hanselman Blog
Wiki
CP

Custom Errors in ASP.NET

Suraj Sahoo — Sun, 01 Feb 2015 13:43:36 +0000

When the yellow screen of death appears, users get distracted!! Throw them at a beautiful & different Page… let’s learn…

Introduction

Recently, while going through the Exception handling and logging, I found an interesting topic which I would like to share – “Exceptions“, which is a family member to every language/technology used. These are sometimes irritating for the developers. If it’s irritating for developers, what would be the condition of the end user when he/she views the “yellow screen populated with God knows what!“.

Now the question arises, should they be displayed with that entire stack trace that is sometimes helpful for developers to resolve errors? The answer obviously is “NO”.

Here is a small tip that might be handy. Here, I am trying to detail the Use of “Custom Errors“and its attributesand elements. Web.config, the main settings and configuration for an ASP.NET web application, is the file where the custom errors find its existence.

According to MSDN, custom errors elements provide information about custom error messages. The main motive here is to display the end user custom error pages. First, let’s know how the custom errors are written in the web.config (as we know in XML format):

The Modes Used

On

Prevents the stack trace that is shown when exceptions arise
Also allows to display custom error pages to the end user
Custom error pages shown to both Remote Clients as well as Local

Off

Makes the end user view the description of the exception along with the entire stack trace.
ASP.NET error/exception and stack trace shown to both Remote clients and Local as well.

Remote Only

This is the best among all for the developers’ perspective, as this allows the Remote clients to view thecustom error messages/pages.
Allows the Local users/especially developers to view the ASP.NET errors.
This is the default value.

Some More Facts

Another attribute that is used is “defaultRedirect“. This is an optional attribute that is used to redirect the browser to the default error page if any, else generic errors are shown to the users.

This is the best amongst all from the developers’ perspective, as this allows the Remote clients to view thecustom error messages/pages.
Allows the Local users/especially developers to view the ASP.NET errors.
This is the default value.
There are also child elements used inside the scope of the customErrors. The one which I have used and came across is the error element. This might be handy if there is a requirement to show specific error pages for specific HttpStatusCodes(401,404,500).

Another important thing to note is Custom Errors can be defined in two levels:

Application Level: Where we use customErrros described above &
Page Level: Where we define in the Page directive, i.e., for specific pages. Use of “ErrorPage” attribute is done here.

We also handle exceptions in Global.asax, i.e. using:

protected void Application_Error(Object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();  //self explanatory gets the most recent error
    Server.ClearError();  //self explanatory clears the error 
        //(Required to clear as otherwise user gets to see the default ASP.NET error handlers)
    Response.Redirect(""); //default redirect. 
}

Now the precedence, that is:

Quote:

When all are defined, then Page level will have higher precedence that global.asax and customErrors. And if the customErrors are also defined along with in Global.asax, then customErrors will have no effect and if no exception handling is done in the global.asax, then Web.config that is customErrorscome into action.

Points of Interest

Note

Flexibility is more in Global.asax as we can redirect the user anywhere we want and also we can log the exceptions into DB/azure blobs writing codes on the server side.
Also, if in application, only one generic error page is required to show, then it’s better to handle inGlobal.asax, else if as per status codes then better is customErrors in Web.config.
When using Handling in Global.asax, remember that the exception object needs to be retrieved before the user gets redirected to custom error page. Thus if not retrieved in the Global.asax, then the exception object is lost and Server.GetLastError() returns null.
For better understanding: If Global.asax has only:
```
protected void Application_Error(Object sender, EventArgs e)
{ 
    Response.Redirect("HandleException.htm"); //default redirect.
}
```
& in the ErrorController.cs and here in the method, we try to retrieve the error object, then we get null.
The reason behind this is the flow. When the exception occurs, it tries to be handled in global.asax Application_Error method (above written method) that only redirects the user to Error/HandleException & the user lands here on redirection only because of the error, thus the error is lost once user gets redirected.

Here, I end this. Thanks for reading. Hope you learnt something from this.

References:

DotNet Tricks