Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Am I running under IIS?

I've got a .NET object that needs to perform a slightly different action if it's running under IIS. Running "normally" (non IIS) I need to do one thing, running under IIS I need to take a slightly differrent action. (Don't ask).

How can I, from within the object itself, tell if it's running under IIS. I've gotten it to work via a config file, but that requires someone to actually *remember* to tell it that it's running under IIS.

Can I determine this at run time in a relatively simple manner?

Thanks.

Sgt. Sausage
Monday, June 06, 2005

If HttpContext.Current is not null then you are running under IIS.

Jeff Mastry
Monday, June 06, 2005

Thanks -- that did the trick -- tested it out and it works.

As you might be able to tell, I'm new to web programming (I'm a database guy). I've got a related question: At what point is the HttpContext.Current initialized? Is there any point in the event stream on the web side that it's not initialized yet and == null may be true, even on the web side?

Sgt. Sausage
Monday, June 06, 2005

I couldn't find an explicit "this thing lives forever" in the docs but, according to MSDN, HttpContext is initialized and provided to all IHttpModule and IHttpHandler implementations. This inlcudes the Page class of course, so I think it's safe to assume it is always valid.

I have a couple of Remoting objects in production that do differnet things (i.e. caching) based on the value in HttpContext.Current and it has never failed me (yet).

Jeff Mastry
Monday, June 06, 2005

HttpContext.Current will be valid any time your object is called as a part of processing an HTTP request. It may work very well for you, but...

There should be situations when HttpContext.Current is not defined even inside a web application:

- Session OnEnd and Application OnEnd handlers
- Calling methods on timer events in a worker thread
- In Finalize method of your object

I didn't verify those, but logically the app server cannot provide you a  meaningful HttpContext.Current in those cases. Even if it happens to work if one of those situations, API does not guarantee it and it may break in a future IIS.

Dmitri Chatokhine
Monday, June 06, 2005

*  Recent Topics

*  Fog Creek Home