Here’s
a yummy and odd thing. I hooked up some global error handling in my big ASP.NET
app. I put it in two places.
The first place was
a handler for the Error event in the base class for all my pages. I had a call
to log4net to log the error and a Redirect that would show the user a friendly explanation
of what went wrong.
The second place was
the Application Error handler in Global.Asax.cs. Same drill. This handler
is for errors that happen outside the scope of my base class (like ASHX files, etc).
Remember that the call
to Redirect (Transfer in one case) was commented out for development. It was
commented out for months and months. I uncommented it today.
Suddenly I started
seeing this ominous dialog when running Visual Studio.NET. NOTE: I said RUNNING
VS.NET, not running the app. I get this as soon as the CSProj gets loaded! Eek!
This stumped me, as
this dialog is the kind of thing you see when you’re not the DebuggerUsers Group,
yada yada yada. I googled some, and all the references to this dialog refer
to permissions and such, and this was clearly not a permission thing as nothing had
changed in that ‘hood.
Since I had log4net
(glorious, BTW) hooked up, I setup the FileAppender to log all my copious Debug statements
to a file. I launched VS.NET and loaded the project. Turned out some of
my pages were being flat-out executed either as VS.NET asked for them from
IIS or as they were loaded into the Designer (I’ve complained about this designer
thing before). In my Init() of a deep base class a I was checking Request.UserLanguages[0]
for the user’s preferred language. Yeah, I know, I didn’t check
to see if [0] was there. It always has been! Well, apparently it’s
not there when VS.NET calls with HTTP to IIS.
Long story short, a
NullReferenceException occurred which was now CAUGHT by my Exception handler and I
tried to call Response.Transfer which boogered up VS.NET who decided that Debugging
was never going to work. Preventing that exception stopped this strange VS.NET
startup error.
Happy New Year!