Random Thoughts

I recently integrated ELMAH (Error Logging Modules and Handlers) with our Azure application. ELMAH is an excellent error logging and reporting libary available for ASP.Net. We used ELMAH for logging all unhandled service exceptions in WCF and ASP.Net. While there is information available on internet about how to integrate these technologies, data is scattered in bits and pieces. My aim through this blog post is to details the steps required for integration. The scenario of usage is, we wanted to log all unhandled exception thrown by our WCF service layer in a database which in our case was SQL Azure. Once done we could easily navigate to the the elmah default url to get a nice report on what errors were being generated by the application. Had it been a typical ASP.Net application, integrating ELMAH is a piece of cake. But since we were working on a Azure web deployment with SQL Azure as the backend some tweaks were necessary. Here are the things to do to get ELMAH fully functional in...

Working with ASP.Net and SilverLight in my current project i learned two important things today SL will always show generic NotFound exception for a remote call failures irrespective of what was returned from server. This limitation roots in the browser which does not pass the exception details to the SL plugin. The only way around is to always send a responses which have Fault property for the SL client to work with. ASP.Net forms authentication mechanism always redirects on 404 error and behaviour is hard to change. This becomes a problem working with SL or ASP.Net MVC clients which expect Http error code (REST clients). The workaround that i found on Stackoverflow was to thrown 403 Error Code instead of 401. This way service calls made from SL or ASP.Net MVC can return http status codes (REST endpoints) and will not cause server redirects.