Hoy me he estado volviendo loco con Visual Studio 2008 SP1. Resulta que necesitaba hacer capturas de pantalla de la barra de propiedades, para lo cual la desacoplaba dellateral, donde la suelo tener, y hacía la captura. Luego la volvía a poner la barra en su sitio.

Bien, nada más hacer eso, si se me ocurría ejecutar la aplicación con F5: ¡crassss! cuelgue miserable de Visual Studio y el ordenador medio colgado (casi no me dejaba sacar ni el administrador de tareas para matarlo) :-((

Al principio no lo asocié a lo de desacoplar la ventana pero luego me di cuenta de que era claramente por eso. Así qeu buscando, buscando llegué a este artículo de la Knowledge Base de Microsoft.

Resulta que hay un bug en el Service Pack 1 de Visual Studio que puede hacer que cuando desacoplas ventanas y las vuelves a coplar algo vaya mal y se te cuelgue el entorno (y de paso casi el sistema).

Desde el enlace anterior te puedes bajar el parche que te proporcionan "por el buen rollito" pero del cual no se responsabilizan, es decir, no es un fix soportado oficialmente pero dicen que lo soluciona.

Tarda alrededor de media vida en instalarse... :-(

...pero parece que arregla el problema :-)

Yo tengo en mi equipo todo instalado en inglés, así que no puedo decirte si funcionará también con la versión en Español del entorno. Si alguien lo prueba en otro idioma y es tan amable, que deje un comentario aquí para los demás. Gracias.

Espero que a alguien le pueda resultar útil.

Soy fan de esos pequeños detalles de calidad que muchas veces pasan inadvertidos pero que, una vez descubiertos, no puedes vivir sin ellos.

En este caso me gustaría hablar de una nueva característica del depurador de Visual Studio 2010 que me resulta muy útil y que echo de menos cuando tengo que volver a versiones anteriores: las inspecciones/watches flotantes.

Quizá no lo hayas notado, pero cuando te colocas encima de una variable o de una expresión cualquiera en el código mientras estás depurando, en la habitual ventanita flotante que te permite inspeccionar las variables y los objetos verás una especie de cuadrito amarillo a la derecha,como en la figura siguiente (por cierto, depurando JavaScript, o sea que funciona con todos los lenguajes):

Si lo pulsas verás que la ventana flotante se convierte en el típico Post-it que se queda visible de forma permanente, y puedes arrastrar a donde queiras. De este modo puedes tener tus objetos de interés siempre visibles, de manera mucho más cómoda que añadiendo una simple inspección a la lista de inspecciones (watch list).

Además tenemos otras ventas ya que nos permite añadir notas debajo para no olvidarnos de cosas importantes relacioandas con cada inspección, así como modificar los valores de las variables y propiedades, cambio que se ve reflejado de inmediato  en el programa que estamos depurando:

Ya sabes, si no los habías visto no pierdas tiempo y empieza a sacarles partido :-)

JavaScript es un lenguaje que, cuatos más años pasan, más de moda está. En los tiempos que corren, con las aplicaciones AJAX campando a sus anchas por todas partes está más presente que nunca, así que no viene mal un truco de vez en cuando (y pienso que en los próximos meses escribiré aún más sobre el tema).

Hoy me he acordado del operador triple-igual o ===. Sí, estás leyendo bien, tres iguales seguidos. No contentos con el doble igual típico de C, C#, Java y otros lenguajes, también tenemos el triple. Este es un operador muy poco conocido en el lenguaje JavaScript y básicamente sirve para comparar la igualdad de dos objetos sin forzar la conversión automática de tipos.

Es decir, que para que devuelve true los dos objetos además de representar el mismo valor deberán ser exactamente del mismo tipo subyacente.

Así por ejemplo, vamos a comparar el == y el === con varios ejemplos:

1 == "1" --> true
1 === "1" --> false (son iguales pero uno es un número y el otro una cadena)
-1 == true --> true
1 == true --> true (tanto el -1 como el 1 se consideran equivalentes a un verdadero cuando se tratan como booleanos)
-1 === true --> false
1 === true --> false
1.0 == 1 --> true
1.0 === 1 --> true también ¡Ojo! JavaScript no distingue subtipos entre los números por lo que ambos son numéricos y por lo tanto del mismo tipo.

Espero que quede claro con los ejemplos. Se trata de un operador muy útil en algunas circunstancias.

El AJAX Control Toolkit nos permite añadir más de 30 controles a nuestras aplicaicones Web para mejorar enormemente su interfaz de usuario. Tenemos desde simples mejoras estéticas como sombras, diálogos o validaciones mejoradas hasta complejos controles como un editor HTML o animaciones.

Para añadirlo a nuestro Visual Studio sólo hay que crear un nuevo grupo en la barra de herramientas y usar la opción "Elegir elementos" (Choose Items si eres como yo y usas siempre la versión en inglés) para seleccionar la DLL del Toolkit y que los controles estén disponibles en VS:

El problema es que en Visual Studio 2010, al pulsar "Browse" y seleccionar la DLL del Toolkit se produce un error y no deja cargar los controles:

"Could not load file or assembly 'file:///C:\AjaxControlToolkit\AjaxControlToolkit.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)"

El motivo es el tratamiento especial que hace la versión 4.0 de .NET de los ensamblados bajados de Internet. El sistema operativo marca con un indicador especial a los ensamblados descargados de cualquier recurso remoto (Internet o una carpeta compartida en la red local). De este modo pueden ser reconocidos como posibles amenazas de seguridad al proceder, a priori, de un origen no confiable como es Internet. El sistema operativo los trata de una forma diferente debido a esto aunque los tengamos copiados ya en una carpeta local. Sin embargo .NET en sus versiones anteriores a la 4.0 hacía caso omiso de esta información sobre el origen y al estar ubicados en local los trataba como ensamblados confiables (por eso no te falla en VS2008 o anterior). Como mejora de seguridad en .NET 4.0 se tiene en cuenta esta particularidad y limita la capacidad de todos estos .exe o .dll que se descarguen directamente o dentro de un ZIP desde una ubicación remota. Por este motivo la DLL del AJAX Control Toolkit no es capaz de cargarse en el entorno de Visual Studio.

Para solucionarlo lo que tenemos que hacer es desbloquear su funcionalidad. Para ello localiza la DLL del toolkit en tu disco duro y en sus propiedades verás un botón "Desbloquear" que sirve precisamente para esto (la captura la he hecho en Windows 7 RC):

Necesitarás permisos de administrador para que el botón funcione (si no, le darás y creerás que ha funcionado pero no es cierto), así que si estás en una carpeta de sistema (como por ejemplo la de Archivos de Programa) mueve antes la DLL a otro lugar, cambia este atributo y devuélvela a su sitio original.

Ahora repite la operación anterior y verás como el problema desaparece y los controles se incorporan a tu barra de herramientas.

Enla actual versión Beta de Visual Studio 2010 no funciona la integración con el entorno de estos controles (al menos en el mío no), de modo que no aparece el diálogo de asociar el extensor con un control que tengas seleccionado, como en VS2008. Es de suponer que estará arreglado en la versión definitiva.

¡Espero que te sea útil!

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.

Desde hace unas horas está ya disponible para descarga la versión definitiva de Silverlight 3.0. Esta versión viene cargada de nuevas e interesantes características: mejoras en streaming, soporte para codecs externos, sketchflow para prototipado visual y rápido de interfaces, gráficos en perspectiva 3D, soporte para skins, nuevos controles avanzados y funcionamiento fuera del navegador entre otras cosas.

Además, al mismo tiempo, se han liberado también las "Silverlight 3 Tools for Visual Studio 2008 SP1". Se trata de una extensión gratuita para Visual Studio 2008 SP1 que habilita el desarrollo en la nueva plataforma.

La descarga incluye entre otras cosas:

· Silverlight 3 developer runtime
· Silverlight 3 software development kit
· Plantillas de proyecto para Visual Basic y C#
· Intellisense y generadores de código para XAML
· Depuración de aplicaciones Silverlight 3.0
· Depuración remota de aplicaciones Silverlight ubicadas en Mac
· Plantillas WCF
· Soporte para Team Build y build desde línea de comandos
· Soporte para aplicaciones Silverliht 3.0 de tipo "Out-of-Browser"

En campusMVP ya estamos ultimando nuestro nuevo curso de Silverlight 3.0, que estará disponible a la vuelta de las vacaciones :-)

Impresionante vídeo que reproduce la visión para dentro de unos años de Microsoft. Dura unos cinco minutos y merece la pena aguantar todo el tiempo. Ojalá la mitad de lo que se muestra ahí llegue a producirse, y ojalá algunas de esas cosas (como el papel digital alucinante que se ve) llegue muy pronto:

Pulsa sobre la imagen para verlo

Este es uno de los problemas/bugs más raros con los que me he topado en años, y puede llegar a ser desesperante. Si has llegado aquí a través de una búsqueda de Google porque tienes el problema que indico en el título del post, estoy seguro de que me vas a dejar una nota de agradecimiento por el consejo :-)

Hace unos días hicimos una nueva plantilla estética para un cliente de nuestra plataforma de e-Learning, SELF. La plataforma tiene un sistema muy potente de plantillas estéticas que permite personalizar mucho la estética y parte de la funcionalidad de la interfaz. Se pueden asociar plantillas a los diferentes campus (entornos cerrados de formación) y también se pueden asignar muchas plantillas/fachadas diferentes a cada campus de forma que se pueda acceder con aspectos diferentes para cada cliente al mismo campus a través de diferentes URLs o directorios virtuales.

Una de estas plantillas, preciosa por cierto, provocaba un extraño efecto sobre todas y cada una de las páginas de la plataforma: se enviaban dos veces. Daba igual que pulsaras sobre un enñace, enviaras un formulario o simplemente llamaras a una página desde la barra de direcciones del navegador: TODAS las páginas se cargaban dos veces. Lo peor del asunto es que, cuando se enviaba un formlario, el primer envío del mismo era normal, pero el segundo y misterioso de ellos, se enviaba sin valor alguno, por lo que se producían excepciones constantemente debido a falta de los parámetros apropiados.

Esta doble petición de páginas no es muy evidente porque se suceden de forma rapidísima. De hecho no nos dimos cuenta de que esto era lo que estaba pasando hasta que analizamos el tráfico entre el navegador y el servidor usando Fiddler. Con esta herramienta detectamos que se estaba produciendo este doble envío de las páginas, lo que fué un avance, pero por más que revisábamos el código del servidor y las cabeceras no veíamos nada que pudiera estar provocándolo.

Cambiando la plantilla no pasaba, por lo que era evidente que había algo en ésta que lo estaba provocando. ¿Pero el qué? No había script con código de navegación, no había directivas de redirección, los archivos auxiliares (CSS, imágenes, etc...) existían todos por lo que tampoco era nuestra página de gestión de errores 404 la que podía estar interfiriendo...

?¿?¿?¿?

La solución

Tras analizar a fondo el código HTML de la página a ver qué encontrábamos vimos lo siguiente en una tabla:

<table border="0" cellpadding="5" cellspacing="0" background="#EFEFEF" width="100%">

¿Ves algo raro en ella?

Nosotros al principio tampoco. El fallo está en el atributo para establecer el color de fondo. El atributo background se usa para establecer la imagen de fondo de la tabla, pero no el color de fondo. Resulta que todos los navegadores importantes tienen un extraño comportamiento con esta etiqueta y es que cuando se introduce algo en ella que no es la ruta de una imagen provoca que se solicite nuevamente la página al servidor. Alucinante. Pasa tanto en Internet Explorer (cualquier versión, incluso la 8.0) y en Firefox (lo mismo), y no lo probamos en otros pero seguramente pasará también.

La solución fué fácil: utilizar el atributo correcto para el color de fondo, bgcolor.

Pero claro, para llegar a aislar el problema y llegar a esta conclusión tuvimos que perder varias horas ya que la plantilla tenía muchísimas líneas de código pues era bastante compleja.

Esta es una de esas cosas raras de narices que aprendes con la experiencia y que no puedes encontrar en un curso o un libro :-(

Espero que leer este post te ahorre horas de frustración :-)

Ya he hablado en otras ocasiones de aplicaciones Web de gran impacto y que están rematadamente mal hechas y sin pensar en el usuario. Ésta vez me toca hablar de la Oficina Virtual de Correos.es, el operador nacional de correo en España.

Hace unos días tuve que enviar un Burofax y me dije: "Ya que esta gente tiene una oficina on-line que incluso ha llevado premios, vamos a hacerlo directamente por Internet, que será coser y cantar". ¡Qué error cometí!.

El problema más grave fue sin duda el que se refiere a los pagos on-line. Resulta que estableces los parámetros del servicio que quieres utilizar y cuando ya lo tienes en el carrito de la compra te da la opción depagarlo on-line inmediatamente. Para ello debes introducir el número de tu tarjeta de crédito y, en teoría, se procesa el pago y el servicio queda listo para ser gestionado or un atento funcionario (perdón, ahora desde que no son monopolio del Estado son "personal laboral fijo",aunque algún funcionario queda). El problema es que tras introducir los datos de la tarjeta y continuar te sale un mensaje diciendo que la tarjeta tiene un problema y no se ha podido cargar el importe en la misma. "¡Qué raro!, pero si yo pago muchísimas cosas con esta tarjeta sin problema", pensé. Así que lo que hice fué intentarlo con otra diferente. Mismo resultado. Y finalmente con una tercera y mismo resultado. El problema es que de repente me entran los SMS avisándome de los cargos en las tarjetas. "¿Cómo?, pero si no me lo podían cargar y aquí sigue pendiente el pago". Llamo al teléfono del banco de Correos (que amablemente facilitaban en el mensaje de error), y me confirman que los cargos sí que han tenido éxito y que en realidad aunque el servicio figuraba como "no pagado" ¡me lo habían cobrado tres veces!.

Increible. Lo peor es que según la operadora que me atendió recibían muchas llamadas como la mía porque le pasaba a todo el mundo y que Correos lo sabía desde al menos hacía una semana. Para denunciarlos :-(((

Al final llamé a soporte técnico de Correos y tuve la suerte de que me tocó (a la segunda, porque la primera vez me dijeron que igual "era un virus o algo" o "que estaba entrando mucha gente") una chica muy espabilada y atenta que sabía de lo que estaba hablando anulé el pedido y a los pocos días me devolvieron el dinero en las tres tarjetas. Por supuesto, tuve que ir a una oficia física a poner el Burofax, con el correspondiente tiempo perdido sumado a la más de una hora que perdí intentándolo por Internet. Y luego quieren acercar la administración al ciudadano :-(((

De todos modos aproveché y saqué algunas conclusiones sobre la aplicación Web de Correos.es que merece la pena compartir.

Primeramente: la aplicación está hecha con ASP.NET 1.1 (al menos le tienen aplicado el Service Pack 1, menos da una piedra):

¿Y cómo lo sé? Pues como se puede observar por la captura, la aplicación rompe bastante, y cuando lo hace muestra todos los detalles de los errores. Esta es la primera mala práctica de seguridad que todo programador mínimamente decente de .NET tiene que saber: No se pueden mostrar los errores detallados a los usuarios. De hecho para hacerlo hay que cambiar a propósito el web.config, así que para mi aún tiene más delito que otros errores. Es más, el hecho de que no haya una página especialmente creada para gestionar estos problemas de manera elegante denota una gran falta de esmero a la hora de hacer la aplicación. Y por supuesto revela que la aplicación no está instrumentada y que probablemente nadie se entera de los errores, y si te dedicas toda la tarde a echar abajo la aplicaicón o a saltarte la seguridad, nadie hará nada por evitarlo.

Deben de mezclar alguna aplicación antigua con las páginas de esta porque de vez en cuando te saltan errores (por supuesto también visibles) que hacen referencia a VBScript, o sea, a ASP 3.0 Clásico:

Lo peor es que estos errores a veces te dan pistas sobre la estructura de disco del servidor y facilitan mucho al que quiera entrar como Pedro por su casa:

De vez en cuando la aplicación pierde la sesión, y en lugar de comprobarlo y obligarte a autenticarte de nuevo, pasan cosas como esta:

O sea, te salen las plantillas de los controles vacíos. Mola ¿no? ;-)

Por fin el peor de los errores (aparte del de mostrar los mensajes de error detallados) que vi en el rato que estuve: deben de tener un Web Farm o un Web Garden para atender a las peticiones y lo tienen mal configurado, por lo que cada dos por tres al pulsar un enlace para ir a otra página te sale esta bonita página de error:

O sea, ¿el que montó esto no sabía que cuando varios servidores atienden las peticiones de una aplicación web deben tener las claves de máquina sincronizadas para evitar que falle la validación del ViewState, las cookies de autenticación, etc?. Una coña marinera.

Cuanto daño hace el "body shopping" de algunas consultoras :-(((

¿Y sabeis lo peor del caso? Que como se ve que no están muy contentos con la aplicación, hace ya más de un año sacaron a concurso el hacer una nueva en Java/J2EE. Claro, seguro que algún iluminado dentro de la empresa dijo "Esto no vale para nada. Vamos a tirar a la basura la millonada que hemos gastado en la anterior y vamos a hacer una nueva. Eso sí, la próxima la quiero en J2EE y con Oracle, que esto de .NET es una mierda, ya lo veis". Claro, probablemente no habrán pensado que la tecnología es lo de menos si la gente que la utiliza no sabe cómo utilizarla bien. De momento no hay nada en J2EE así que ya veremos cuando la sustituyan. O ¿se habrán echado atrás en el último momento?.

En fin, siento la longitud y la acritud que refleja de este post, pero es que hay cosas con las que no puedo.  A una empresa pequeña no le pasan ni la mitad de lo que le pasan a estas empresas grandes pseudo-monopolistas :-(

Otro día os hablaré de otras, que ejemplos hay muchísimos.

La semana pasada os contaba en un post la forma de eliminar la caché de salida de una página a voluntad, antes de que caduque de manera "natural", usando el método RemoveOutputCacheItem. Este método tiene el problema de que debemos hacerlo desde una página diferente a la que está cacheada, porque en ésta los eventos de servidor (incluyendo el click de un botón) no saltan. Además dejé planteado un caso relativamente común que se puede dar y en el que resultaría útil disponer de otra forma de controlar si se hace caché o no.

Imagina esta situación: tienes una página en caché que los usuarios normales pueden ver pero no editar, pero que los administradores pueden cambiar usando los botones apropiados. Si simplemente activas la caché para que los usuarios vean la versión cacheada de la página, como hemos visto, ninguno de los eventos normales saltará, así que los administradores tampoco podrán editar nada, ni tampoco se verán los cambios que han hecho hasta que la caché se refresque. ¿Cómo podemos conseguir que la caché salte únicamente para los usuarios normales, pero que para los editores o administradores la página funcione con normalidad?

La primera tentación es pensar en hacer caché de la página con un VaryByCustom, que guarde en caché una versión diferente de la salida página según quien sea el usuario actualmente autenticado en el sistema. Esto está bien excepto por un pequeño problema: que aunque sí serviría para crear una versión diferente en caché de la página por cada tipo de usuario (o el criterio que elijamos), no nos permite no hacer caché. Es decir, no podemos anularla por ejemplo para los administradores y hacerla para el resto de perfiles, que es lo que buscábamos. Así que este camino es un punto muerto.

La técnica para conseguirlo pasa por el uso de un evento especial de la caché que es llamado automáticamente una vez en cada petición. Para ello disponemos del método AddValidationCallback. Éste toma como argumentos la referencia a un delegado del tipo HttpCacheValidateHandler, y un objeto cualquiera que sirve para pasar los datos que necesitemos a la llamada (normalmente lo usaremos con una referencia nula).

Así, en el evento de carga de la página pondremos este código:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
    lblHora.Text = DateTime.Now.ToLongTimeString()
    If User.Identity.IsAuthenticated Then
        Response.Cache.AddValidationCallback(New HttpCacheValidateHandler(AddressOf ValidateCache), Nothing)
    End If
End Sub

El evento Load saltará siempre que la página no esté en Caché, es decir, la primera vez que llamemos a la página. En este caso lo que hacemos es que si el usuario actual está autenticado, asignamos la función ValidateCache como la responsable de decidir en cada petición la validez de la caché actual de la página.

Ahora sólo resta definir el manejador del evento, que será como este:

Public Shared Sub ValidateCache(ByVal Currentcontext As HttpContext, ByVal data As Object, _
ByRef status As HttpValidationStatus)

    If Currentcontext.User.IsInRole("Administradores") Then
        status = HttpValidationStatus.IgnoreThisRequest
    Else
        status = HttpValidationStatus.Valid
    End If

End Sub

Lo que se hace es comprobar si el usuario actual está dentro del rol de "Administradores", en cuyo casi devolvemos como estátus de validación de caché el valor IgnoreThisRequest de la enumeración HttpValidationStatus. Al hacer esto lo que conseguimos es que se obvie la caché para la página, y por lo tanto ésta se ejecute normalmente.

Si el usuario es cualquier otro tipo de usuario validamos la caché (con el valor Valid de la misma enumeración) de forma que ésta actuará de la manera habitual.

Con esto conseguimos el efecto buscado que es que la caché se realice para todos los usuarios excepto para los administradores, de foram que puedan trabajar en ella normalmente.

En un programa real iríamos un paso más allá e invalidaríamos la caché de la página con la técnica aprendida en el post anterior siempre que un administrador cambiara algún dato en la página, dando acceso inmediato a la nueva versión a todos los usuarios.

Aunque antes he dicho que cuando la página está en caché los eventos de ésta no saltan, éste evento de validación saltará siempre (en todas las peticiones) porque no es se trata de un evento de la página, sino un evento de la propia caché, y por lo tanto ajeno al ciclo de vido de la página (pero no al ciclo de vida de una petición). No te dejes engañar por el hecho de que el código del evento esté en la propia página.

Una sutileza más

Antes de dar por terminado el post. La enumeración HttpValidationStatus aún tiene un valor más aparte de los dos que acabamos de ver. Se trata del valor HttpValidationStatus.Invalid. Si utilizamos este valor en lugar de HttpValidationStatus.IgnoreThisRequest, como en el ejemplo, aparentemente la técnica funcionará igual, pues se saltará la caché para los administradores y permitirá que estos trabajen en la página con todos sus eventos. 

Sin embargo hay una diferencia importante: cuando usamos HttpValidationStatus.IgnoreThisRequest lo que conseguimos es saltarnos el uso de la caché, de forma que la página se ejecuta normalmente y la caché existente no se ve afectada, quedando intacta para el resto de los usuarios. Sin embargo cuando usamos el valor HttpValidationStatus.Invalid lo que indicamos es que la caché actual ya no vale (lo que técnicamente se conoce como "fallo de caché" o "cahé miss" e inglés), y por lo tanto el efecto conseguido es que se elimina la caché que existiera en ese momento para la página, se ejecuta ésta y se genera una nueva versión cacheada de la misma.

La diferencia es tremenda. En el primer caso nos la saltamos sin afectarla, pero en el segundo lo que hacemos es generar una versión nueva para todos los usuarios, con las implicaciones de rendimiento y posible visualización de información consistente que ello implica. Así que hay que tenerlo en cuenta.

Obviamente podemo usar HttpValidationStatus.Invalid para borrar la caché en casos que realmente así lo requieran, pero hay que tener en cuenta los posibles efectos.

Este tema está realmente pobremente documentado y es muy poco conocido, así que espero que te resulte de utilidad :-)