One common ASP.NET performance tip is to remove any
HttpModules that your application does not use. You can take a peek at which modules are loaded by the framework on your behalf by examining the framework’s
Web.config file, but how do you find out which modules are actually loaded in the current context?
In an ASP.NET page, if you call
Request.QueryString.ToString(), you’ll get a nicely formatted query string back, like this:
“That’s nice,” I thought. “I wonder how they implemented it. I’ll fire up Reflector and take a look.”
A couple of months ago, I ran into a problem where I was seeing a bunch of
ThreadAbortExceptions showing up in my logs. It didn’t take long to track down why – I was calling
Response.Redirect from within a
try/catch block in my ASP.NET code-behind page, and the catch block was catching the
ThreadAbortException and writing it out to the log. But why was the
ThreadAbortException being generated?