Thread: Using ELMAH with AsptDotNetStorefront

Hello,

Does anyone have any experience using ELMAH (http://code.google.com/p/elmah/) for logging errors with AspDotNetStorefront ML 7.1.0.0? If so, have you been able to get the error log that displays when hitting elmah.axd to display correctly?

I have ELMAH up and running and it is capturing errors and logging them correctly. However when I view elmah.axd it is returning a 404 for the detail pages, css styles etc.

Based on this blog post describing a similar issue (http://csharpin.blogspot.com/2009/03...and-elmah.html) I'm starting to suspect maybe something similar is happening with the ASPDNSF.URLRewriter.

If anyone has an idea for a workaround I'd like to hear about it as having a log viewable from the browser is very useful.

Thanks,
Matt

EDIT: I forgot to add this is currently under IIS6 on Windows 2003 server

If you get no other answers, check back here on Monday. I had never heard of ELMAH but looked at it and LOVE it. Im going to set it up on my test server this weekend and will report back on Monday.

Ok, so here are my findings. I was able to get almost everything working based on this discussion http://markmail.org/message/jbxekauw...+state:results

The trick was mapping all the modules in the web.config

Code:

<add verb="GET,HEAD,POST" path="elmah.axd/detail" type="Elmah.ErrorDetailPage,
Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/html" type="Elmah.ErrorHtmlPage,
Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/rss" type="Elmah.ErrorRssHandler,
Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/digestrss"
type="Elmah.ErrorDigestRssHandler, Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/xml" type="Elmah.ErrorXmlHandler,
Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/download"
type="Elmah.ErrorLogDownloadHandler, Elmah" />
<add verb="GET,HEAD,POST" path="elmah.axd/about" type="Elmah.AboutPage, Elmah"
/>

The only thing that did not work was the style sheet ... not quite sure why.

Also, this was all locally ... once I moved it to my testing server it would no longer log any errors. Have not figured that out yet.

the reason the css is not being applied is it's getting an invalid request by virtue of it's url structure. "elmah.axd/stylesheet"
Behind the scenes the UrlRewriter kicks off and tries to interpret that pattern, thereby blocking the Elmah's ErrorLogPageFactory to kick off.

What you can do as a work-around instead, though would require source code, is there's a hook in the application to suppress the url-rewriter. AppLogic.cs/Custom_Application_BeginRequest_Logic

C#/VB.NET Code:

public static bool Custom_Application_BeginRequest_Logic(Object sender, EventArgs e)
        {
            // put any custom application begin request logic you need here...
            // return TRUE if you do NOT want our UrlRewriter to fire
            // return FALSE if you do want our UrlRewriter to fire and handle this event
            // do not change this routine unless you know exactly what you are doing
            HttpContext ctx = HttpContext.Current;
            if (ctx != null)
            {
                if (ctx.Request.Url.PathAndQuery.Contains("elmah.axd"))
                {
                    // suppress url-rewriting
                    return true;
                }
            }

            return false;
        } 


Though useful, Elmah doesn't provide fine grained access control of the error logs, by design it only validates for signed-in customers. You'd have to implement the logic to validate that user as an store admin; not unless you want the error logs to be publicly accessible.

Anothing thing is, we just have this kind of error handling feature baked in the application available on the next major release of ML.
There are new appconfig settings that you can toggle to control error handling/logging.

Anothing thing is, we just have this kind of error handling feature baked in the application available on the next major release of ML.

That is excellent news! One thing i've done is I put in email/txt alerts when fedex/ups fails to return rates. Fedex in general just seems to go down often and I like to know when it goes down so I can activate UPS.

ssgumby and ASPDNSF Staff - Mark - Thanks for taking the time to look into this a figure out what was going on.

I appreciate it.

An alternative I found to the application_beginrequest fix for the stylesheet issue (using version 7.x):


1. Save the Elmah css file somewhere on your site: http://elmah.googlecode.com/svn/trun...h/ErrorLog.css

2. Add the following to the urlrewrites section in web.config

HTML Code:

<rule url="/elmah.axd(.*)/stylesheet" rewrite="/path/to/ErrorLog.css" />

And that's it. You'll still need to add those other modules from earlier in the thread to cover other paths.




Another hurdle I ran into is that I wanted to use the SQL database for Elmah's log, but Elmah wants the connection string specified in the <connectionStrings> section, while AspDotNetStorefront wants it in <appSettings>. How to avoid having to include the same connection string twice? Some digging in Elmah's source code revealed an alternative:

HTML Code:

<elmah>
        <security allowRemoteAccess="1" /> <!-- set this to 0 to only allow report access from localhost -->
	<errorLog type="Elmah.SqlErrorLog, Elmah" 
            connectionStringAppKey="DBConn" /> 
</elmah>

By specifying connectionStringAppKey instead of connectionStringName, it can pull the connection string from the same place as AspDotNetStorefront.




Finally, to secure the error report pages, just add this to web.config:

HTML Code:

<location path="elmah.axd">  
    <system.web>  
        <authorization>  
	     <allow roles="Admin"/>
	     <deny users="*"/>
        </authorization>  
    </system.web>  
</location> 

AspDotNetStorefront already takes care of adding the admin users to the Admin role.

We've been thoroughly enjoying the benefits of ELMAH on our site, helped us track down several errors that we had no idea were going on as much as they were.

However, I wanted to ask if any of you all have manage to get ELMAH to report XmlPackage Exceptions.

Because XmlPackage Exceptions are "soft" errors and don't cause the entire page to break, ELMAH is not logging them....so there is absolutely no way to know if there is a broken package somewhere that might be causing problems for customers.

I'd LOVE to be able to log XmlPackage Exceptions in ELMAH! This would be the ultimate help for us.