UrlRewriting.Net Module + IIS7 Igual a Page.User == null?

Question

He usado el módulo UrlRewriting.Net desde hace un par de años sin ningún problema en Windows XP y Windows 2003. Hace poco actualicé mi PC hogareña a Windows 7 y comencé a desarrollar un nuevo sitio web.

El plan era utilizar extensiones .html y volver a escribirlas en sus contrapartes .aspx utilizando el módulo UrlRewriting.Net. Todo funciona sin problemas en VWD 2008, pero cuando intento ejecutarlo a través de IIS7, es una historia diferente.

Cuando intento acceder a una página mediante la revisión .html, ya no puedo acceder a Page.User; sigue volviendo nulo. Si toco la página con su extensión .aspx, la página. El usuario está correctamente poblado. También debo mencionar que tengo un controlador LoginView en mi página maestra y que sufre los mismos síntomas: al acceder a través de la extensión .html, muestra la plantilla Anonyous; Al usar la extensión .aspx, muestra correctamente LoggedInTemplate. Supongo que los dos están relacionados.

[Nota: También he intentado URL sin extensión y exhiben el mismo problema]

La única forma que he conseguido que funcione es cambiar el grupo de aplicaciones a la versión clásica, que luego me obliga a añadir un controlador ddl de ASP.Net para la extensión .html [de lo contrario, es manejado por el StaticFileHandler y aparece como un error 404]. Sin embargo, me gustaría que mi aplicación web se ejecute correctamente para las personas sin tener que jugar con IIS.

Así que me quedo con varias preguntas:

• ¿alguien tiene idea de por qué Page.User siempre es igual a cero para .html => .aspx reescrita páginas?
• ¿Por qué funciona en VWD 2008, pero no en IIS7?
• ¿Qué ha cambiado de IIS6 => IIS7 que podría haber causado esto?
• ¿Alguna otra idea sobre soluciones temporales?

[Nota: Acabo de intentar una .aspx => .aspx reescribir y no presentó el problema. No es realmente lo que quiero, pero pensé que debería mencionarlo.]

Answer 1

Acaba de salir adelante con el módulo UrlRewriting.Net. Esto hace que funcione en el modo integrado en IIS 7:

<modules runAllManagedModulesForAllRequests="true">

Después de averiguarlo Hice una búsqueda en "runAllManagedModulesForAllRequests" y lo primero que apareció fue Scott Guthrie's blog que en realidad habla de utilizarlo para este propósito.

Answer 2

Otro enfoque que parece funcionar es eliminar el módulo de sesión y leerlo dejando la casilla de verificación "Invocar solo para peticiones a aplicaciones ASP.NET o controladores administrados" sin marcar. Parece que este en el archivo web.config:

<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> 

Parece que el problema es que el módulo de sesión no se ejecuta para decir '' * .htm archivos cuando se utiliza HttpContext.RewritePath, pero la eliminación y readding el módulo de esta manera hace que el controlador de sesión se ejecute para la solicitud.

Se sugirió esta solución en el siguiente hilo.Por desgracia, Microsoft optó por no explicar el razonamiento detrás de este comportamiento totalmente:

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

Answer 3

Microsoft incluyó una solución para este problema (al menos para las direcciones URL sin extensión) en el Service Pack 1 para Win7 y Windows Server 2008 R2: http://www.microsoft.com/download/en/details.aspx?id=5842

también disponible como una revisión: http://support.microsoft.com/kb/980368

Después de aplicar este parche, ASP.NET 4 aplicaciones pueden manejar las solicitudes de URL sin extensión. Por lo tanto, se ejecutarán los HttpModules administrados que se ejecutan antes de la ejecución del manejador. En algunos casos, los HttpModules pueden devolver errores para URLs sin extensión. Por ejemplo, un HttpModule que se escribió para esperar únicamente solicitudes .aspx ahora puede devolver errores cuando intenta acceder a la propiedad HttpContext.Session.

Después de aplicar SP1 o la revisión, no se necesitan cambios en la configuración web para que la sesión y las formas de autenticación funcionen para las URL sin extensión reescritas en asp.net pages/handlers/etc.

No sé si esto soluciona algo para reescribir en extensiones de archivos estáticos como .htm. Creo que es probable que no. Intentaría evitar establecer runAllManagedModulesForAllRequests = "true" en entornos de producción, porque agrega una sobrecarga innecesaria en las solicitudes de archivos estáticos.