Registrar la .Net Framework

Esta es una operación sencilla para la cual tomaré como referencia una pregunta de stackoverflow.com que pueden ver en este link:

http://stackoverflow.com/questions/647598/how-to-register-asp-net-2-0-to-web-serveriis7

Podemos utilizar también Web Platform Installer segun se detalla en el siguiente punto: Instalar MVC 2.0

La opción más conocida es utilizar “aspnet.regiis.exe” el cual se encuentra en el path de la framework que estemos utilizando, por ejemplo para registrar la .Net Framework 2.0 en iis podemos utilizar:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe –ir

Cabe mencionar que la Framework 3.5 para ser utilizada en un website registramos la Framework 2.0 y en nuestro web.config referenciamos los assembly de la framework 3.5. Usualmente Visual Studio realiza esta configuracion por nosotros siempre y cuando la “targeting platform” sea la framework 3.5.

Instalar MVC 2

Para instalar MVC 2.0 es recomendable utilizar Microsoft Web Platform Installer , una vez lo tenemos instalado en nuestro IIS Manager seleccionamos el sitio web y buscamos el ícono de Web Platform Installer

Luego dentro de “Web Platform” seleccionamos la opción “Customize” dentro de “Frameworks and Runtimes”

Finalmente marcamos dentro de las opciones de “.NET Framework” lo que necesitamos (en este caso ASP.NET MVC 2)

Configurar el Website.

Para comenzar podemos dar click derecho en el folder “Sites” de nuestro server dentro del IIS Manager y seleccionar la opción “Add Web Site…”

Luego en el formulario de configuracion definimos el nombre del sitio, la ubicación de los archivos, la dirección IP a donde llegarán los requests y el nombre de dominio que utilizaremos.

Crear un “Wildcard Script Map” para MVC

Para esto seleccionamos el sitio web en nuestro IIS Manager y damos doble click en el ícono de “Handler Mappings”

Luego seleccionamos “Add Wildcard Script Map…” dentro del menú de acciones

y llenamos el form como se muestra a continuación…

Se recomienda utilizar el mismo Ejecutable que se tiene para el script map de “PageHandlerFactory”. Ojo, en el caso de que su sistema operativo sea 64 bit el path cambia. Por ejemplo:

Si el path donde tenemos instalada nuestra framework (32bit) es C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll podemos utilizar para 64bit el path C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll

Me atrevo a decir, que si tenemos dos script map para PageHandlerFactory como se muestra en la siguiente imagen:

seguramente necesitaremos crear dos wildcard script map para MVC

La creación de este wildcard script map es importante ya que MVC necesita que a los requests les sean aplicados los ruteos de nuestra aplicación.

Publicar Los Archivos de nuestro Website

“Para gustos se rompen generos” dicen por allí, asi que cada quien queda en libertad de seleccionar cuál es su forma preferida para colocar los archivos dentro del path definido al configurar nuestro sitio web, copiando los archivos, haciendo deploy con visual studio, etc…

• Puede ser utilizada como una API de cache para almacenar objetos y variables de PHP.
• Tiene la opción de configurarse como Session Handler de PHP con persistencia en disco.

Entre las características que posee esta extensión estan:

• Cache del bytecode de PHP en memoria, agilizando el tiempo de respuesta al no tener que parsear completamente los scripts PHP, lo cual reduce tambien el I/O overhead.
• Debido a que la persistencia de los elementos en cache es en disco, situaciones como un Reciclado de los application pools no afectan en el cache ya creado.
• Soporta las notificaciones de cambio de archivos, permitiendo refrescar los bytecodes en cache.
• Cuenta con funciones de PHP para conocer el estado del cache.

Creo que es una buena alternativa a utilizar en IIS para mejorar el performance de nuestras aplicaciones en PHP reduciendo el tiempo de interpretación de los scripts.

Para mayores detalles de uso podemos consultar el Manual de PHP sobre Windows Cache y para otros recursos sobre la extensión pueden consultar el blog de RuslanY con el post original.

Algunos links sobre Session State y la opción de SQL Server Session Mode

Overview en CodePoject

How-To de Microsoft Support

Fast, Scalable, and Secure Session State Management for Your Web Applications

En ocasiones, al cambiar de servidor dado a la distribución que realiza un load balancer, la aplicación parecía no poder obtener la información almacenada en sesión y por ende no poder continuar con el proceso que debía desarrollar. Al momento de revisar la base de datos de sesión pudimos percatarnos que habían 2 tuplas para una misma ASP.NetSessionId

Query: select * from ASPStateTempSessions where SessionId like '%piltae45debwl355ek3v0545%'

Y cómo es esto? Ok, resulta que el SessionId que utilizamos en nuestra aplicación no es lo único que se utiliza como llave en la tabla de SQL ya que está formada por:

Session Id + Application Id

(ver mas info acá: Session State Providers)

Resultó entonces que por cada servidor nos estaba generando una tupla en nuestro storage de sesión, la primera con la información que habíamos almacenado y la segunda como una nueva sesión totalmente vacía. Esto debido a que a cada webserver le estaba asignando un diferente Application Id.

Me dirán por ahí que esto no debía suceder… también hay un trasfondo relacionado con la aplicación que casualmente permite esto, sin embargo esto lo dejamos para otro post

Solución:

Debemos irnos a cada uno de los webservers del WebGarden y en cada uno debemos definir el “ID” del website. Para ello debemos colocarnos en “Sites”

Dar click derecho y en “Manage Web Site” seleccionamos la opción “Advanced Settings”

y finalmente nos aseguramos que el Website en cada uno de los Web Servers de nuestro WebGarden tenga el mismo ID

Reiniciamos los IIS para que todo camine en orden y voila!