views:

120

answers:

2

The basic idea is we have a test enviroment which mimics Production so customErrors="RemoteOnly". We just built a test harness that runs against the Test enviroment and detects breaks. We would like it to be able to pull back the detailed error. But we don't want to turn customErrors="On" because then it doesn't mimic Production.

I've looked around and thought a lot, and everything I've come up with isn't possible. Am I wrong about any of these points?

  • We can't turn customErrors on at runtime because when you call configuration.Save() - it writes the web.config to disk and now it's Off for every request.
  • We can't symlink the files into a new top level directory with it's own web.config because we're on windows and subversion on windows doesn't do symlinks.
  • We can't use URL-Mapping to make an empty folder dir2 with its own web.config and make the files in dir1 appear to be in dir2 - the web.config doesn't apply
  • We can't copy all the aspx files into dir2 with it's own web.config because none of the links would be consistent and it's a horrible hacky solution.
  • We can't change customErrors in web.config based on hostname (e.g. add another dns entry to the test server) because it's not possible/supported
  • We can't do any virtual directory shenanigans to make it work.

If I'm not, is there a way to accomplish what I'm trying to do? Turn on customErrors site-wide under certain circumstances (dns name or even a querystring value)?

+1  A: 

If you have customErrors="On" or "remoteOnly" the error detail doesnt go away right? I mean you can still access it and log it to another source using your custom error page.

Why dont you just have your custom error page in production log the information somewhere your harness can access it, like a message queue or App event log? When the harness comes across a break it just has to be smart enough to do a lookup in the right place for the full error info.

Another thing to consider anyway.

Tj Kellie
That's the hack we've put together right now that gets us 60% of the way there, 50% of the time. But we're using nUnitASP for the harness, and it does great parsing of the yellow page of death to give you error details. I was hoping to regain that.
Tom Ritter
A: 

Check out ELMAH http://code.google.com/p/elmah/. Lets you grab error info without interfering with your app and without displaying the YSOD to your users.

dbugger