0 Comments

Available on NuGet

Including ELFAR (MVC) and ELFAR (Web API) in your web application is extremely easy.  However, if you're anything like me then you'll hate the idea of having to create two instances of the error log provider (assuming that you've referenced the same providers).  You can manually combine the files but, to save you the bother, I've done the leg work for you:

0 Comments

Introduction

There has been a steady uptake of Error Logging Filter and Route (ELFAR) for ASP.NET MVC since I introduced it, back in February.  Just a few days before that post, Microsoft released ASP.NET MVC 4 Beta (now RC), which includes ASP.NET Web API.  Although part of ASP.NET MVC 4, ASP.NET Web API uses completely different namespaces (and can be hosted independently), which means that ELFAR couldn't be plugged in automatically, so I decided to see if it was possible to adapt ELFAR for ASP.NET Web API.

Adapting ELFAR

As the two technologies follow the same architecture, it was a simple process to create the Web API ErrorLogFilter and ErrorLogRoute.  They are almost identical to the MVC ErrorLogFilter and ErrorLogRoute, apart from the base classes that they derive from (and the Web API ErrorLogRoute doesn't need to override the GetRouteData or GetVirtualPath methods).  However, to maintain the separation of concerns between ASP.NET MVC and ASP.NET Web API, the common interfaces and classes needed to be moved out of the MVC class library and into their own class library (Elfar.Core).  With that, Error Logging Filter and Route (ELFAR) for ASP.NET Web API was created.

Like ELFAR (MVC), add ELFAR (Web API) to your website/web application with just 4 lines of code (usually in the Application_Start method):

var config = GlobalConfiguration.Configuration;
var provider = new ErrorLogProvider();
config.Filters.Add(new ErrorLogFilter(provider));
config.Routes.Add("elfar", new ErrorLogRoute(provider));
Figure 1

The same but different

Whilst the filters behave identically, the routes provide very different functionality.  Where the MVC version provides the web GUI, for viewing the error logs, the Web API version acts as an ErrorLogProvider by returning either the list of error logs or a single error log.

Available on NuGet

ELFAR (Web API) uses the same error log providers as ELFAR (MVC):

0 Comments

Erik Funkenbusch posted a question, on the ELFAR discussion board, regarding the logging of handled exceptions. He managed to figure out a solution and kindly posted it:

FYI, I found a solution that works pretty well.

try
{
    throw new NotImplementedException();
}
catch (Exception e)
{
    foreach (var filter in GlobalFilters.Filters)
    {
        if (filter.Instance is ErrorLogFilter)
        {
            var f = filter.Instance as ErrorLogFilter;
            f.OnException(new ExceptionContext(ControllerContext, e));
        }
    }
}

I actually took this one step further and created a .Log() extension method on Exception.

public static class ExceptionExtensions
{
    public static void Log(this Exception exception, ControllerContext context)
    {
        foreach (var filter in GlobalFilters.Filters)
        {
            if (filter.Instance is ErrorLogFilter)
            {
                var f = filter.Instance as ErrorLogFilter;
                f.OnException(new ExceptionContext(context, exception));
            }
        }
    }
}

Then you just need to use it as such:

try
{
    throw new NotImplementedException();
}
catch (Exception e)
{
    //...
    e.Log(ControllerContext);
}

However, there is an alternative solution: throw the exception and let ELFAR automatically handle it (Figure 1).

try
{
    throw new NotImplementedException();
}
catch (Exception)
{
    //...
    throw;
}
Figure 1

Update:

Erik responded with some good points:

Rethrowing the exception will result in an unhandle exception propogating to the client...The whole point is to handle th[e] exception, but log it so it can be investigated. I find this particularly useful with exceptions for external resources (Web requests, file access, etc..). There is no point in passing this on to the user if you can continue.

0 Comments

Introduction

Error Logging Filter and Route (ELFAR) for ASP.NET MVC was inspired by and based on the popular Error Logging Modules And Handlers (ELMAH) for ASP.NET utility. ELFAR retains the familiar ELMAH user interface but has been built to utilise the architecture of ASP.NET MVC. Unlike ELMAH, ELFAR is not driven by configuration and can be added to your website/web application with just 3 lines of code (usually in the Application_Start method):

var provider = new ErrorLogProvider();
GlobalFilters.Filters.Add(new ErrorLogFilter(provider));
RouteTable.Routes.Insert(0, new ErrorLogRoute(provider));
Figure 1

To access ELFAR, navigate to ~/elfar (where ~/ is the root directory of the MVC application).

Available on NuGet

ELFAR has 6 out-of-the-box error log providers:

Features

Once ELFAR has been added to your website/web application, you get the following features:

  • a web page to view a list of error logs
  • a web page to view the details of an error log, including a coloured stack trace
  • a view of the original yellow screen of death (where appropriate)
  • XML and JSON downloads of the error log
  • an RSS feed of the last 15 error logs
  • an RSS digest of daily error logs (limited to 900)
  • a CSV download of all error logs
    •    

Optional features

In addition, there are several optional features available:

  • Excluding unwanted exceptions
  • Restricting access to the ELFAR web pages
  • Email notification of errors   
  • Posting errors to Twitter
    •    

Resources

Further information can be found in the ELFAR Wiki.
Full source for ELFAR can be found at SourceForge.net (Subversion) or GitHub

0 Comments

This is an article that I wrote on 8th November 2004, which I later removed from my old website.  Fortunately, it had been copied verbatim and translated into VB.NET (although neither of them acknowledge that it's my article), so I thought I'd add it to my new blog (with some minor code adjustments).

Introduction

A common problem that Web Application Developers encounter is how to stop the user from refreshing the page. This is a problem if the previous request to the server was a PostBack, which, for example, inserted the WebForm’s data into a database. The result: duplicate rows in the database. The answer to this problem is that you can’t stop the user from refreshing the page, however there is a way to determine if this event has occurred.

In his article “Build Your ASP.NET Pages on a Richer Bedrock” [no longer available] Dino Esposito outlined a mechanism to detect a page refresh. This method is cumbersome and more complicated than necessary, although the fundamental idea is sound and forms the basis of this solution. Dino’s mechanism uses a counter stored on the page and a session variable to store the previous request’s counter on the server, if the two match then we have a page refresh.

A simpler method

Keeping the whole process within a base Page class ensures that the mechanism is completely encapsulated (and simple to implement) and if we use ViewState we eliminate the need to use an additional hidden field. Also, as we simply want to test if the two storage devices contain the same value, we can use two boolean variables, which further simplifies the process.

The last decision to make is where, in the Page’s lifecycle, should the process take place. As we are using ViewState it would seem logical to perform the operation in the LoadViewState and SaveViewState methods. Using these two methods, and not the OnLoad method, has further benefits in that it eliminates potential problems with derived classes implementing Page_Load.

How the process works

The LoadViewState method, which is part of the Page’s initialisation phase, is only invoked during PostBack and therefore SaveViewState is the only method, of the two ViewState related methods, to be called when the page is first requested.

protected override object SaveViewState()
{
    SessionState = RefreshState;
    var allStates = new object[2];
    allStates[0] = base.SaveViewState();
    allStates[1] = !RefreshState;
    return allStates;
}
Figure 1

Note: RefreshState (which on initial page request is defaulted to false and on subsequent PostBack requests is the value of ViewState) is assigned to the SessionState item and the negated RefreshState is saved to the new ViewState.

Once a PostBack event takes place the LoadViewState method is called.

protected override void LoadViewState(object savedState)
{
    var allStates = (object[]) savedState;
    base.LoadViewState(allStates[0]);
    RefreshState = (bool) allStates[1];
    IsRefresh = RefreshState == SessionState;
}
Figure 2

Note: The RefreshState is retrieved from ViewState and compared with the value in the SessionState. The result is stored in IsRefresh Property.

The listing below shows the entire class definition:

namespace StevenBey.Web.UI
{
    public class Page : System.Web.UI.Page
    {
        protected override void LoadViewState(object savedState)
        {
            var = (object[]) savedState;
            base.LoadViewState(allStates[0]);
            RefreshState = (bool) allStates[1];
            IsRefresh = RefreshState == SessionState;
        }
        protected override object SaveViewState()
        {
            SessionState = RefreshState;
            var = new object[2];
            allStates[0] = base.SaveViewState();
            allStates[1] = !RefreshState;
            return allStates;
        }
        public bool IsRefresh { get; private set; }
        bool RefreshState { get; set; }
        bool SessionState
        {
            get { return (bool) Session["__ISREFRESH"]; }
            set { Session["__ISREFRESH"] = value; }
        }
    }
}
Figure 3

Testing the process

<%@ Page Inherits="StevenBey.Web.UI.Page" %>
<html>
    <head>
        <title>Detecting Page Refresh</title>
    </head>
    <body>
        IsRefresh = <%= IsRefresh %>
        <form runat="server">
            <asp:Button runat="server" Text="Submit" />
        </form>
    </body>
</html>
Figure 4

Clicking on the button invokes a PostBack, however the value of IsRefresh doesn’t change until you click on the browser’s Refresh button or press F5 on the keyboard (and then click “Retry”). Clicking on the button once again resets the value of IsRefresh to false.

Conclusion

In this article I have demonstrated a simplified method of detecting a page refresh event.