Si llevas unos cuantos años en esto del desarrollo Web seguro que tienes todavía aplicaciones por ahí escritas en ASP 3.0, también conocido como "ASP Clásico". Este precursor del actual ASP era estupendo y funciona de maravilla aún hoy en día. A pesar de todas las virguerías técnicas existentes en la actualidad (que me encantan) me confieso un enamorado de esa antigua plataforma.

El caso es que aún hoy en día, si tienes que montar una aplicación de ASP 3.0 incluso en un moderno Windows Server 2008 R2 con IIS 7.5, podrás hacerlo sin problemas y funcionará todo de maravilla. O casi...

El otro día tuvimos que montar una de nuestras aplicaciones "legacy" en este entorno precisamente y todo parecía ir de maravilla. El caso es que nosotros instrumentamos todas nuestras aplicaciones, incluso  las antiguas, para llevar un registro automático de todos los eventos de interés que se producen: avisos, advertencias, operaciones importantes sobre los datos... y por supuesto los errores no gestionados y por tanto inesperados. Se trata de una buena práctica que deberías seguir en cualquier aplicación, y más en una para Internet y de la cual algunos ya me habréis oído hablar en ponencias por ahí.

En ASP clásico la forma de gestionar los errores inesperados pasa necesariamente por personalizar la página de error para el estátus 500 del servidor Web con una página .asp propia. En ésta se obtiene información sobre el error producido usando el método Server.GetLastError que devuelve un objeto ASPError con todos los detalles.

La configuración en IIS 7.0 o IIS 7.5 se hace de la siguiente forma:

1.- En las propiedades del servidor virtual se va a la sección de páginas de error:

2.- Una vez dentro de ésta aparecen la lista de códigos de estátus HTTP estándar, como por ejemplo el 404 para páginas no encontradas (muy recomendable gestionarlo), el 302 (acceso denegado), o el que nos interesa: 50, error interno del servidor. Sustituimos la página por defecto de IIS para el error 500 y colocamos una página .asp propia. Utilizando el mencionado objeto ASPError podemos obtener información sobre errores que se produzcan, anotar información sobre lo que ha pasado con todo lujo de detalles (error, tipo, ubicación, página, usuario, tipo de navegador...) para luego poder hacer un diagnóstico y detectar problemas. También devolveremos una página más bonita y adecuada para los usuarios, lo cual es muy importante también, y además es una buena práctica de seguridad el no mostrar mensajes detallados de error al usuario final.

No funciona en IIS 7.x

La idea es estupenda y funciona muy bien si lo hacemos en IIS 5.0 o 6.0, ¡pero en IIS 7.x no funcionará!. Es decir, sí que se llamará a nuestra página personalizada, y ésta funcionará. El problema es que el método Server.GetLastError devolverá un objeto con todas sus propiedades vacías, por lo que sabremos que se produce un error pero no tendremos ni un sólo detalle del mismo :-(

Se trata de un bug reconocido por Microsoft desde IIS 7.0, pero que no ha sido corregido en ninguno de los Service Pack ni tampoco en la versión R2 del sistema operativo (nueva versión 7.5 de IIS). Son los riesgos de usar una tecnología antigua para la que Microsoft no tiene la menor intención de seguir invirtiendo ni un segundo.

¿Cómo lo solucionamos?

Como casi siempre hay una vía de escape para solventar el problema. IIS 7.x dispone de un gestor global de códigos de estado HTTP que se usa cuando no hay uno específicamente designado en la configuración. Resulta que en este gestor global de errores el objeto ASPError sí que se rellena correctamente.

Por lo tanto lo que tenemos que hacer es eliminar el estátus HTTP 500 de la lista de errores gestionados por IIS, para que no tenga asignada ni siquiera la página por defecto. Si editamos la configuración general de este módulo de gestión global de errores:

Nos aparece un diálogo en el que podremos ajustar nuestra página de gestión global:

Allí deberemos introducir una ruta relativa a la raíz de nuestra aplicación (por ejemplo "/Logevents/logerr.asp" como en la figura), y usar en el PathType la opción de "Ejecutar una URL".

De este modo se recibirán perfectamente las propiedades del error y podremos trabajar como siempre :-)

¡Uppps! IIS me da un error de "violación de bloqueo" (Lock Violation)

Vaya. Cuando ya pensábamos que lo teníamos controlado y podríamos tener nuestra aplicación ASP Clásico funcionando a pleno rendimiento, al pulsar "OK" en el diálogo de la figura anterior nos sale este mensaje:

¿Qué demonios es esto? La verdad es que el mensaje no proporciona demasiada información al respecto. He de confesar que cuando nos salio la primera vez pensé que era un bug de la interfaz de gestión de IIS 7.5, que tenía interbloqueos mal hechos ;-P

A base de indagar y probar, ya que no había información en Internet al respecto y la poca que hay no está bien, llegué a la solución del problema.

Por defecto, hay ciertas secciones de la configuración global de IIS 7.x que están protegidas para impedir la modifiación en sub-ramas del servidor. Esto está diseñado de esta forma pensando en las empresas de hosting, ya que de esta manera pueden bloquear ciertas secciones peligrosas para que los administradores de los sitios web que venden no puedan cambiar ajustes que puedan comprometer la seguridad global del servidor. ¡Bien hecho Microsoft!. Lo malo es que no está nada claro en ningún sitio (o al menos a mi eso me parece), y a más de uno que gestiona sus propios servidores le puede traer por la calle de la amargura. ¡Mal hecho Microsoft! ;-)

En nuestro caso lo que debemos hacer es desbloquear este ajuste en la configuración global del servidor para que nos permita cambiarlo en la configuración secundaria de los sitios Web.

Para ello debes ir, como administrador, a la carpeta "C:\Windows\System32\Inetsrv" o equivalente (está ahí incluso en versiones de 64 bits de Windows). Dentro de ésta encontrarás el archivo applicationHost.config. Sácale una copia por si acaso te cargas algo que no debes, y ábrelo con el bloc de notas, ya que es un simple archivo de texto XML.

Una vez abierto busca el nodo "<httpErrors>". Encontrarás una rama que pondrá algo similar a esto:

<httpErrors defaultPath="" defaultResponseMode="ExecuteURL"
lockAttributes="allowAbsolutePathsWhenDelegated,defaultPath">

La parte importante aquí es el atributo lockAttributes. Como puedes observar, por defecto, tiene bloqueada la modificación de la ruta por defecto para los errores, que es precisamente lo que pretendemos modificar en nuestro sitio web.

Elimina la palabra "defaultPath" del atributo lockAttributes, graba el archivo y ciérralo. Ahora vuelve a IIS y cambia d enuevo la configuración en el diálgoo que hemos visto. Esta vez, al cerrarlo, no te generará la violación de bloqueo, y todos felices.

Este último consejo te valdrá para IIS en general, y por lo tanto para ASP.NET o incluso PHP, y no se restringe sólo a esta sección de la configuración.

Espero que si llegas hasta aquí a través de un búsqueda, desesperado/a por el problema, todo esto te haya servido. Si me lo quieres agradecer puedes dejar un comentario, y también ya sabes ;-)

Si has actualizado tu sistema a Windows 7 desde Windows Vista, es posible que en ciertos escenarios concretos se produzca un problema que fuerce el sistema a estar reiniciándose constantemente. Microsoft no ha dado detalles de en qué condiciones ocurre, aunque serán casos excepcionales.

Lo que pasa es que, tras instalar Windows 7 sobre Vista te sale un mensaje que dice "Esta versión de Windows no ha podido ser instalada. Tu anterior versión de Windows se ha restaurado y puedes continuar usándola". Entonces se reinicia el sistema y lo que pasa realmente es que se reinicia la instalación y sale el mismo mensaje, atrapándote en una espiral infernal.

Al parecer Vista sí está realmente restaurado en el equipo, pero la base de datos de configuración de arranque del sistema (BCD, Boot Configuration Database) está mal actualizada y por eso sigue intentando restaurarlo.

La solución es manual y pasa or hacer lo siguiente:

1.- Introducir el DVD de Windows Vista con el que instalaste el sistema inicial y salir de la instalación de Vista cuando comience.

2.- Ejecutar la línea de comandos como administrador.

3.- Ejecutar esta instrucción:  D:\boot\BootSec.exe /NT60 All   (sustituye D: por la unidad en la que esté el CD de instalación de Vista)

4.- Reiniciar

Con esto se soluciona el problema y puedes seguir utilizando Vista. Acto seguido yo instalaría Windows 7 desde cero. Merece mucho la pena el nuevo sistema.

Espero que a alguien le pueda ayudar.

ACLARACIÓN: esto no me ha ocurrido a mi ni tampoco sé de nadie a quien le haya ocurrido tampoco. Lo he encontrado de casualidad por ahí y me he hecho eco simplemente.

Windows 7 mola mucho. Desde las primeras betas internas, no disponibles para el público, ya se le veía que no tenía nada que ver con versiones anteriores (y sigo diciendo que Vista mola también y que a pesar de algunos de los problemas que ha tenido es el mejor que SO que había hecho MS hasta que salió Win7).

Al grano. Una de las cosas que primero llama la atención, claro está, es la nueva interfaz de usuario. Lo que no todo el mundo sabe es que además de ser bonita también es muy útil. Y una de las caratcerísticas más útiles es la de la nueva gestión de ventanas.

Si arrastras una ventana hacia la parte superior de la pantalla se maximiza. Si le haces doble click sobre el borde inferior o superior de la misma se maximiza pero en vertical sólo. Puedes conseguir lo mismo con las teclas Windows+Flecha arriba y Windows+ Flecha abajo para maximiizar/restaurar y Windows+Mays+Flecha Arriba y Windows+Mays+Flecha Abajo, para maximizar restaurar en vertical.

Un efecto simpático es que si agarras una ventana por su barra de título y la meneas de un lado a otro todas las demás ventanas se minimizan y haciéndolo de nuevo se restauran a sus anterior posiciones (puedes conseguir lo mismo pulsando Windows + Inicio)

Algo mucho más útil es la posibilidad de acoplar ventanas a los laterales. Por ejemplo, si estás comparando dos documentos, o si necesitas trabajar con una documentación en una ventana mientras escribes en otra, o si programas con Visual Studio 2010 y tienes en una ventana flotante el código de una página y en la otra la vista previa :-) Para conseguirlo sólo tienes que arrastrar la ventana pegándola a uno de los bordes y se acoplará a él. Arrastra la otra al otro borde y se acoplará de forma que entre las dos se repartan la pantalla a medias para trabajar. Realmente útil sobre todo en los monitores panorámicos omnipresentes hoy en día. Puedes conseguir el mismo efecto en lugar de arrastrando las ventanas, usando las teclas rápidas: Windows+Flecha Derecha y Windows+Flecha Izquierda.

Finalmente, si eres de los que comoa mi le gusta trabajar con dos monitores, puedes pasar rápidamente una ventana de un monitor a otro con tan sólo pulsar las combinaciones de teclas Windows+Mays+Flecha izquierda y Windows+Mays+Flecha derecha.

Lo que yo me pregunto es: ¿para cuando una gestión multiescritorio nativa como la que tienen las X en Linux sin tener que recurrir a programas de terceros? ¿Tan complicado es incluir el soporte el S.O.? :-(

Espero que te resulte útil.

Sí, el sistema operativo que nunca has querido usar cumple 40 años ;-)

Como seguro que sabes, UNIX es la base de todas las distribuciones de Linux, pero ¿sabías que Mac OS X está basado también en este sistema operativo?. Obviamente también es la base de otros sistemas como Solaris, Irix, AIX, o BSD. Y ¿sabías que el UNIX con mayor implantación era de Microsoft?. Se llamaba Xenix, y antes de que llegara Linux fue el que tuvo un mayor número de usuarios.

Puedes saberlo todo sobre la historia de UNIX y sus creadores, los míticos Ken Thomson y Dennis Ritchie en la entrada de UNIX de la Wikipedia.

En realidad se podría decir que, a pesar de la aparente variedad, el mundo de los sistemas operativos se divide en dos: Microsoft Windows y los derivados de UNIX.

El famosísimo gurú Joel Spolsky ha afirmado lo siguiente:

"¿Cuáles son las diferencias culturales entre los programadores de Unix y de Windows?. Existen muchos detalles y sutilezas, pero en su mayor parte se resumen en una sola cosa: la cultura Unix valora el código que es útil para otros programadores, mientras que la cultura Windows valora el código que es útil para los que no son programadores. Esto es, por supuesto, una gran simplificación pero, en realidad, esta es la gran diferencia: ¿Estamos programando para otros programadores o para los usuarios finales?. Todo lo demás son comentarios."

Parece que últimamente los chicos de Linux, al menos en algunas de sus distribuciones, están haciendo un buen trabajo para cambiar esta cultura. Eso es bueno: la competencia fomenta la innovación y la mejora, y es bueno para los usuarios.

¡Felicidades de corazón por este aniversario!

En el post que escribí hace unos días sobre cómo solucionar el problema de los menús de ASP.NET en IE8, comenté que en un futuro post explicaría cómo forzar desde nuestra aplicación que la gente que acceda a la misma con Internet Explorer 8.0 la vea en modo de compatibilidad con Internet Explorer 7.0. Esto es de especial importancia para nosotros si nuestra aplicación no se visualiza bien según los estándares estrictos de CSS 2.1 pero no tenía problemas con la versión anterior de IE.

Dado que, como comentaba en el anterior post, no podemos confiar en que los usuarios vayan a pulsar el botón de compatibilidad si la página se ve mal (simplemente semarcharán o si tenemos mucha suerte intentarán usar Firefox), lo mejor que podemos hacer es forzar de manera transparente para ellos esa compatibilidad.

Para ello disponemos de varias técnicas:

1.- Usar una etiqueta META especial en nuestra página

Si incluimos la siguiente etiqueta META en la cabecera de nuestra página podremos conseguir que el navegador de forma automática y transparente para el usuario utilice el modo de compatibilidad:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7"/>

Ya está. Con esto conseguiremos que, incluso, el agente de usuario del navegador sea como el de IE7, es decir, a todos los efectos el navegador se hará pasar por IE7.

2.- Etiqueta META en todas las páginas

Lo anterior está genial si son una o dos páginas las que presentan problemas. Sin embargo en un sitio Web grande, con decenas o cientos de páginas la cosa ya no es tan interesante pues habría que ir una a una poniendo la cabecera. Para estos casos podemos obligar a que sea la propia infrastructura de ASP.NET la que fuerce la inclusión de la etiqueta en cada una de las páginas. Para ello necesitamos modificar el nodo <system.webServer> dentro del archivo de configuración web.config de nuestra aplicación, así:

El nodo httpProtocol nos permite añadir cabeceras propias a todas las páginas, así como cabeceras de redirección. En este caso añadimos una cabecera normal con la pareja nombre-valor necesaria para forzar la emulación en IE8. Es equivalente a poner en todas las páginas la cabecera META anterior.

3.- Forzar la cabecera de compatibilidad en el servidor

Si quieres forzar que todas las aplicaciones de tu servidor fuercen el modo de compatibilidad, sin tener que ir por cada web.config haciendo lo anterior, puedes incluir dicha cabecera de forma sencilla tanto en IIS 6 como IIS7.

En IIS6 basta con ir a las propiedades de un sitio Web y una vez ahí a la pestaña encabezados:

En IIS 7 es más fácil aún pues se puede establecer para el servidor completo así:

¡Listo!

Si eres de los que programa aplicaciones Web en ASP.NET para Linux o Mac usando Mono, puedes encontrar una guía de la propia Microsoft sobre cómo configurar las cabeceras de compatibilidad para IE8 en Apache.

Algunos detalles más

1.- ¿Y si quiero que ocurra todo lo contrario? Es decir, quiero que siempre se use el modo de compatibilidad total con estándares (es decir modo IE8) aunque el usuario pulse tenga configurado mi dominio para compatibilidad con IE7. Pues se puede hacer lo mismo que he dicho antes pero con esta otra pareja de nombre-valor en una cabecera:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

2.- ¿Cómo distingo que el navegador que me visita es en realidad Internet Explorer 8 en compatibilidad con IE7?. Claro, la pregunta tiene lógica ya que si hasta el agente de usuario se modifica para reflejar que es IE7, ¿cómo hago? Lo puedo necesitar para estadísticas o lo que sea...

Cuando IE8 hace una petición a una página en modo compatibilidad esta es la cadena que usa como agente de usuario (la real en mi propio equipo)

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022; OfficeLiveConnector.1.1; .NET CLR 3.5.30729; .NET CLR 3.0.30618;

Lo importante a destacar aquí es lo que está en negrita. El fragmento inicial, hasta MSIE 7.0, es lo que indica que es IE7 quien solicita la página. No se distinguiría de una petición hecha con el IE7 real (de hecho en IE8 sólo cambia ese número y pondría MSIE 8.0). Lo que la distingue realmente del IE7 real es la otra negrita de arriba: Trident/4.0.

Trident es el nombre del motor de renderizado de páginas de Internet Explorer 8.0, siendo 4.0 su versión. Si buscamos la palabra Trident sabremos que el navegador es realmente IE8.

¡Espero que te resulte útil!