UrlRewriting.Net Module + IIS7 Equals Page.User == null?

Question

I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.

The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.

When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.

[Note: I've also tried extensionless URLs and they exhibit the same problem]

The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.

So I am left with several questions:

• Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
• Why does it work in VWD 2008, but not IIS7?
• What changed from IIS6 => IIS7 that could have caused this?
• Any other thoughts on workarounds?

[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]

Answer 1

Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:

<modules runAllManagedModulesForAllRequests="true">

After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.

Answer 2

Thanks Sam. You are spot on. It does solve the problem. I would vote your answer but dont have enough reputations :(

Answer 3

Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:

<system.webServer>
  <modules>
    <remove name="Session" />
    <add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </modules>
</system.webServer>

It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.

This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:

http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7

Answer 4

Hi,

I had the method mentioned above "remove and then re-add session manually". I did work with my paging but later on when I was creating CMS it started creating problems with Session_Start event in Global.asax. This event was not firing at all.

I then used the method above "runAllManagedModulesForAllRequests", I am glad that I can see my pages back at least for now. Hope there will be no further issues.

So I would like to warn people who are planning to use the first technique.

Thanks for your post, you really solved my problem.