views:

45

answers:

2

Hi,

I'm getting that exception when I try to access the HttpContext.Current.Request object.

I've seen the responses in l1, l2 and l3 ... so... my question then is :

For what in the world are IHttpModules now for?

I wanted to develop a module that gets hit every time a call enter to may website, so I can log the url accessed, the user IP address, etc... , but now it seems I cannot do it anymore in IIS7. Is there any workaround? (besides switch to "Classic Mode").

alt text

Cheers.

A: 

I posted this originally as a comment cause it's not really an answer, but then I saw that you are looking for a "work around" so here's my idea of a work around.

/App_Code/BasePage.vb

 Public Class BasePage : Inherits System.Web.UI.Page
    Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        ''# Do all your logging here
    End Sub
 End Class

/Default.aspx.vb

Partial Class _Default : Inherits BasePage
    ''# This is simply your code behind for each page (notice it inherits BasePage)
    ''# You can still have your Page_Load events along with custom methods in here, 
    ''# and it will not affect the logging portion of your app.
End Class

Basically what you're doing is creating a single class that does the same work on every page load no matter what page is being loaded. Then each page in your application will inherit from the BasePage class in order to activate it.

rockinthesixstring
This can of course be converted to C# if you're using C# by using http://converter.telerik.com
rockinthesixstring
I really appreciate it, but I'm not using ASP.NET UI classes :PThanks!
vtortola
what are you using?
rockinthesixstring
My own UI classes :D Hopefully in the next month I will re-develop them to generate html5 code instead html4.
vtortola
+1  A: 

When are you doing that? is it in a module event? It should be perfectly doable in an integrated pool as well. Bottom-line there are changes on how ASP.NET hooks to IIS when running in Integrated mode that makes it "more first class". This does mean that certain events fire before, for example Application_Start will now fire outside the context of an actual request. Other examples are expecting to have a Windows Authenticated Identity in the BeginRequest, since now BeginRequest happens even before IIS authenticates, which was not the case in the past.

If your application depends on the old bad behavior you can still change your AppPool to run in Classic Mode and it will work just fine.

You should be able to grab the Request in any notifications that are request specific such as BeginRequest, EndRequest, PostAuthorizeRequest, etc. Also, I would recommend against using HttpContext.Current since that incurs an additional look up in a hash table and usually you can get the context directly in other ways, specially in the context of a module, so for example if you handle the BeginRequest, you should be able to do:

    HttpApplication application = (HttpApplication)sender;  
    HttpContext context = application.Context;  

and you will save the lookup.

From your description it sounds like you should be implementing a module that handles BeginRequest and EndRequest and you should be fine.

CarlosAg