Catch unhandled exceptions in ASP.NET

I came across an interesting article about errors occurring outside the context of a request. Apparently, such errors will put an end to your worker process. Source code for a module to catch and log such errors are included in the article, check it out!

Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0.

Some highlights from the RSA Euro conference '10

I just got back from London and the RSA Europe conference, I've had a great week! In addition to a solid program, the conference is a hotspot of highly skilled professionals. I ended up in a lengthy discussion at the Microsoft stand on the possibilities of the new Forefront Threat Management Gateway (TMG), and the Unified Access Gateway (UAG). One chat with a Microsoft professional, and I learned that the UAG is much more versatile than the official webpages indicate. Of course, I had many more interesting conversations with both sponsors and visitors to the conference. I have to mention that I was fortunate enough to bump into Steve Lipner from Microsoft while I was on my way from one session to another. I happened to be carrying around my SDL-book, he was kind enough to sign it. Good stuff!

I'll summarize some of my favorite sessions from the conference:

Keep ASP.NET error pages out of search engines

In a production environment, users should not be presented the default ASP.NET error pages. Instead they should be offered clean, understandable error pages giving them a sensible explanation of the error, along with suggestions to continue their journey on the website. Besides usability concerns, it's also an important security practice to not leak details about application details to those who might tinker with your application!

In ASP.NET, the customErrors configuration element is used to handle error situations. However, the behaviour of the custom errors is somewhat counterintuitive, as you might end up with your error pages indexed by search engines.