ASP.NET healthMonitoring WebErrorEvent / IIS7

[Howard Hoffman]

We've an ASP.NET 2.0 application that we're migrating to IIS7 and W2K8.

We have application that makes heavy use of the
System.Web.Management.WebErrorEvent type to Raise() errors to the configured
ASP.NET health monitoring providers. This has proven to be a good solution
for us over the 3 years the application has been in production.

Our application has logic that fires in the Global.asax Application_Start
event, and that logic also uses the WebErrorEvent type to Raise error
events. This does not work in IIS7 for an Integrated applcation.

In my view, this is a fixable limitation that MS should address and release
as a patch.

The issue is that System.Web.Management.WebRequestInformation class (it is
marked Internal according to Reflector) makes an illegal (when called in the
context of an Application_Start event) call to HttpContext.Current.Request.
Ironically, the WebRequestInformation class does already handle the case
where HttpContext.Current is null, and proceeeds normally after that point.

What happens is that our application only cannot Raise WebErrors
appropriately within Application_Start.

In our case, we're using 3 Providers:

Event Log Provider
SQL Web Event Provider
Templated Mail Web Event Provider

I'm looks to me (again, via Reflector) that all 3 would work just fine
without a live HttpContext.Current.Request.

What is Microsoft's plan for updating System.Web.Management to work in this
case? What is a recommended practice that developers should follow here?

Thanks in advance,

Howard Hoffman

 

[bruce barker]

it looks like a simple bug. you should open a support call.

-- bruce (sqlwork.com)

 

[Howard Hoffman]

I've opened a support bug, and MS is going to take a look.

For others who may run into the issue, here's the boilerplate:

1) System.Web.Management.WebErrorEvent has a dependency on
System.Web.Management.WebRequestInformation.
2) If you attempt to Raise an Event using the WebErrorEvent (or anything
deriving from WebErrorEvent) during the Application_Start event of an IIS7 /
Integrated-pipeline application, you'll get an HttpException.

The issue is the constructor of WebRequestInformation is fired during the
event Raise call. Though that constructor does gracefully handle the case
where HttpContext.Current is null, it access the HttpContext.Current.Request
property when HttpContext.Current is *not* null. That triggers the
Exception. Perhaps they should check HttpRuntime.UsingIntegratedPipeline
first.

With IIS7, and ASP.NET integrated mode, as described here
(http://weblogs.asp.net/reganschrode...s-context-exception-in-application-start.aspx),
HttpContext.Current.Request is inaccessible during Application_Start in an
Integrated Pipeline application.

It does strike me as this is a bug that WebErrorEvent does this. I believe
you should be able to use the WebErrorEvent.Raise method even without an Http
Request.

As Regan menions in his post (noted above), MS "may introduce changes that
further break the assumption that applications start because of requests -
for example, by introducing a warmup mechanism that can start ASP.NET
appliations based on a specific schedule." That'd work for me!

I'd say that one thing you want to be able to do during startup processing
is validate configuration and perhaps kick off background activities. Such
tasks benefit from the good design and implementation of the Health
Monitoring framework.

As a work around, I changed my Application_Start to this:

void Application_Start( Object sender, EventArgs e )
{
<existing code...then:>
HttpContext temp = HttpContext.Current;
try
{
if( HttpRuntime.UsingIntegratedPipeline)
{
HttpContext.Current = null;
}
< existing code that possibly accesses HttpContext.Current.Request
here ... >
}
finally
{
if( HttpRuntime.UsingIntegratedPipeline)
{
HttpContext.Current = temp;
}
}
}

Hope this is useful.