La última versión de ASP.NET, la 4.0, incorpora varias opciones de configuración que tienen que ver con las URLs de nuestras páginas. Por ejemplo: los caracteres que son válidos y, por lo tanto, admitidos en una URL.

Por defecto existen 8 caracteres especiales que no se admiten en la ruta de una página, a saber:

<
>
&
*
%
:

?

La verdad es que es bastante lógico, puesto que no puede existir ningún archivo ni carpeta que los use en su nombre, y además el «et» o «ampersand» (&) y la interrogación (?) forman parte siempre de la parte de parámetros o «Query String» de una URL, no de la ruta.

Cuando se introduce uno de estos caracteres en una URL, ASP.NET devuelve un error 400, de petición errónea:

En ASP.NET 4.0 es posible definir la lista de caracteres no válidos en una URL tocando el web.config de la aplicación, en concreto el nodo httpRuntime en su propiedad requestPathInvalidChars:

<httpRuntime requestPathInvalidChars=»&lt;,&gt;,*,%,&amp;,:,,?»  />

Este es su valor por defecto que como vemos incluye los 8 caracteres que comentaba antes.

Si quisiésemos añadir algunos caracteres más que consideremos que no debemos admitir por seguridad, bastaría con incorporarlos a la lista anterior redefiniendo este nodo dentro de web.config.

Además, hay una serie de caracteres no imprimibles que si se intentaran utilizar producirían el mismo efecto, y no hay forma de quitarlos de la lista. Se trata de todos los caracteres ASCII que están entre el 0 y el 31 (el 32 es el primer caracter imprimible y es es el espacio en blanco). Estos caracteres son siempre no válidos por la misma definición de lo que es una URL, y es el propio sistema operativo a través del módulo http.sys quien se encarga de rechazar esas URLs (ni siquiera llega a .NET).

>> Longitud de las URL

Otro parámetro que ha sido constante hasta ahora en el mundo .NET es la longitud máxima de una ruta de nuestra aplicación: 260 caracteres. El motivo es que esta es la longitud máxima que se admite en el sistema de archivos NTFS, que al final es donde residen los archivos de nuestra aplicación.

Otro límite habitual ha sido el de la longitud máxima de la Query String (lo que va después de la ? en una URL, que define los parámetros de la petición). En ASP.NET el límite ha sido siempre de 2.048 caracteres. De hecho este límite debería ser más que suficiente, aunque la mayor parte de los navegadores lo superan: Internet Explorer soporta «sólo» 2.083 caracteres que ya es superior, pero otros navegadores como Opera (4.050 caracteres), Firefox (8.182 caracteres) o safari (8.184 caracteres) soportan como vemos muchos más.

A veces será útil modificar el límite autoimpuesto por ASP.NET de 2.048 caracteres. La mayor parte de las veces mi consejo sería reducir esta longitud ya que si tienes que enviar realmente tanta información mejor que uses un POST y no un GET, y si permites tamaños muy grandes se podrían utilizar para intentar saturar el servidor o hacer que falle tu aplicación si no se espera algo tan grande y trata de ahcer alguna conversión de datos, por ejemplo.

Tocando el mismo nodo de web.config que en el caso anterior puedes modificar ambos límites en ASP.NET 4.0:

<httpRuntime maxRequestPathLength=»260″ maxQueryStringLength=»2048″ />

El primer parámetro permite definir longitudes de ruta más largas o más cortas (se refiere a la parte de la URL que no es ni el  http://, ni el nombre del servidor, ni el QueryString). El segundo parámetro modifica la longitud permitida en el Query String.

>> Conclusión
Aunque generalmente no necesitarás tocar ninguno de estos parámetros es bueno saber que ahora puedes hacerlo si surge la necesidad. En cualquier caso es raro que una aplicación llegue a necesitar alcanzar esos límites de tamaño en las rutas, por lo que puede ser interesante cambiarlas por defecto para que sean más cortas y disminuir así la superficie de ataque por esta vía.

No te olvides tampoco de que estas limitaciones afectan tanto a peticiones «normales» desde el navegador, como a peticiones Ajax que no ves porque se hacen en segundo plano.

En las últimas semanas he tenido que presentar telemáticamente diversos documentos en otras tantas Administraciones del Estado, tanto locales como nacionales. En todas era necesario, como no, firmar digitalmente ciertos documentos o el propio envío de información en sí. En cada una de ellas el método para conseguirlo era diferente: control ActiveX, programa Java, una combinación de ambos… Lo único que tenían en común es que es un absoluto dolor conseguir llevar a buen término la operación 🙁

Y no digamos también si intentamos usar el DNIe (o “DNI digital”) en un banco o para hacer algún trámite on-line: otro terrible dolor. Es más: yo no he conseguido aún usar mi DNIe con ninguno de los bancos con los que trabajo.

En todos los casos tienes problemas con el software, debes lanzar el navegador como administrador, instalar componentes, y conocer todo tipo de terminología “esotérica” para entender lo que haces. Y si me cuesta a mí que soy un usuario avanzado y entiendo bien el funcionamiento subyacente de todo eso y la terminología, qué no le ocurrirá a un usuario “normal”, con conocimientos básicos de informática. Hoy por hoy veo imposible que mi padre haga un trámite on-line él solo con la administración.

Todo esto me ha hecho pensar en la necesidad de disponer algún tipo de estándar de programación y metodología para todos los navegadores que permita simplificar el uso de la criptografía de clave pública basada en certificados. De este modo el desarrollo y, sobre todo, el uso de estas funcionalidades por parte de los usuarios sería muy sencillo y exento de problemas.

Dado que todos los sistemas operativos del mercado soportan el uso de certificados digitales y que todos los navegadores son capaces de sacarle partido ¿por qué no disponemos ya de algo así?

La primera cosa que se me ocurrió es “la gran esperanza blanca” del desarrollo Web: el futuro HTML5. La verdad es que no me sonaba haber leído en los borradores del estándar nada acerca de criptografía o seguridad de clave pública, pero por si acaso lo verifiqué. En el actual draft de HTML5  no aparece nada al respecto.

Una verdadera lástima.  HTML5 va a suponer una revolución si conseguimos que todos los navegadores lo soporten bien (y parece que hay voluntad de eso), e incluye algunas APIs muy interesantes demandadas por todos los programadores. Pero me parece una verdadera pena que se pierda una oportunidad como está de implicar a todos los fabricantes de navegadores en el soporte de la criptografía de clave pública con una API común promovida por la W3C. Esto por si solo impulsaría de verdad la sociedad de la información, más que los millones de euros gastados en otras cosas 🙁

El caso es que he intentado enterarme del motivo por el que HTML5 no contempla estas capacidades, y si realmente se “les ha olvidado” o no. Lo único que he encontrado es este documento de Anders Rundgren, un ex-ingeniero de RSA, en el que cita y muestra correo intercambiado con la gente del equipo de HTML5 que dicen que lo descartan intencionadamente porque HTML ya es muy grande y no hay mucha demanda para este asunto en particular.

¿Qué no hay mucha demanda? ¡Alucino!. Si no hay demanda de eso que baje Dios y lo vea.

En fin, insisto en creo que se está perdiendo una oportunidad de oro de incorporar un estándar para la implementación de firmas digitales en HTML5, en un momento en el que parece haber consenso en el sector en torno a esta nueva especificación y que ello perjudicará mucho al avance de la sociedad de la información en todo el mundo 🙁

Y tú ¿qué opinas?

No es que en Microsoft se hayan vuelto locos y hayan apostado por el sistema del pingüino. Es simplemente que he estado probando bien las Office Web Apps en este Linux, para ver si son una buena opción para trabajar con Office sin tener verdaderamente el producto instalado. Y la verdad es van muy bien. Y además tienes 25 GB para almacenar lo que quieras 🙂

Desde hace muy poco tiempo, para todo el mundo, en Skydrive ya están integradas las Office Web Apps. Se trata de versiones basadas en Wed de las principales herramientas de la Suite Office 2010, en concreto: Word, Excel, Powerpoint y OneNote, para toma de notas. Ofrecen, evidentemente, una versión recortada de la funcionalidad disponible en la suite de escritorio, pero aún así son una buena alternativa gratuita para disponer de la funcionalidad más básica. Y además tienes 25 GB de espacio para almacenar lo que quieras, no sólo documentos de Office, sino cualquier cosa 🙂

Hace más  de un año, cuando oí hablar de estas aplicaciones internamente en Microsoft y vi las primeras capturas de pantalla, todos pensábamos que iban a estar basadas en Silverlight. La interfaz de usuario es muy compleja y hacerla en Silverlight parecía la opción más sencilla y rápida. Fue toda una sorpresa descubrir hace unos meses, con las primeras betas, que están basadas totalmente en HTML + JavaScript, como Google Docs. Una maravilla y mucho más fácil transportarlas a otros sistemas seguro.

En esta figura (click para ampliarla) se puede ver una presentación hecha en Powerpoint en Firefox bajo Linux abierta en Powerpoint Web App:

Como se puede observar la sensación es la misma que usando Powerpoint 2010, disponiendo del famoso Ribbon escamoteable, la vista previa de las diapositivas en el lateral, formatos, inserción de figuras, efectos de imágenes, varios tipos de plantillas de diapositivas, etc… Y lo mismo con el resto de aplicaciones de la suite. No es tan potente como la versión completa de escritorio, eso desde luego, pero sí es suficiente para lo que hace la mayor parte de los usuarios. Y además permite compartir y colaborar con otras personas directamente on-line, la capacidad de impresión de documentos es realmente buena, y además los tendremos disponibles desde cualquier parte, incluso desde teléfonos móviles para visualización.

Por ejemplo, estas son algunas capturas utilizando Skydrive y las Office Web Apps desde un iPhone (pulsa para ampliar):

Por supuesto se puede usar la pantalla multitátil para hacer zoom en los documentos y leerlos con toda claridad. Muy interesante.

Soporte de Navegadores

En principio estás aplicaciones están soportadas sin problema en Internet Explorer, Firefox y Safari. Microsoft ha dejado fuera del soporte a Google Chrome (mi favorito) alegando cuestiones de incompatibilidad, pero dado que tanto Chrome como Safari están basados en Webkit mi idea es que no debería haber demasiado problema usándolo tampoco, así que lo he probado.

En Windows todo parece funcionar sin problema alguno bajo Chrome. Por ejemplo, esta es una captura usando Word Web App bajo Chrome en Windows 7 (pulsa para ampliar):

Sin embargo, y esto sí que me llama la atención, con la misma versión de Chrome (la última) trabajando en Ubuntu se muestra este inquietante mensaje:

¿A qué será debido? Ni idea. Según tengo entendido Chrome es el mismo código base tanto en Windows como en Linux, pero se ve que alguna diferencia hay, algo que no dice mucho por parte de Chrome. Incluso falla la visualización de los documentos, algo que no pasa ni siquiera en el iPhone como se ve en las pantallas anteriores. En Firefox, como ya se ha visto, no hay problema ni diferencia alguna en Linux o en Windows (y es de suponer que en Mac tampoco, pero no tenía uno a mano para probarlo). Chrome debería tener ofrecer mayor consistencia entre sus versiones para diferentes sistemas operativos.

Silverlight en Linux

Cuando visualizas una presentación Powerpoint en Firefox bajo Linux, aunque está perfectamente soportada su visualización con HTML y JavaScript, se te muestra una franja amarilla de información diciéndote que si instalas Silverlight tendrás mejor rendimiento:

Si pulsas en esa franja te lleva a una página de Microsoft, que tras detectar tu navegador y sistema operativo te lleva a la descarga e instalación directa del plug-in de Moonlight, la versión para Linux de Silverlight hecha en el proyecto Mono.

No la instales (o deshabilita el plug-in). En cuanto lo instalas, aunque hayas instalado también los Codecs adicionales, las presentaciones dejan de verse, mostrándose una pantalla negra. Mejor dejar la versión HTML de las diapositivas.

Por lo demás no hay ningún problema que yo haya visto.

Office web Apps vs Google Docs

Esta es la pregunta del millón. Es más, también habría que compararlas con Zoho Apps, que tiene verdaderas joyas como Zoho Creator, y de las cuales ya he hablado aquí en alguna ocasión.

Esto daría para un amplio artículo o dos, pues hay muchas cosas que comparar. No haré el extenso analisis que requeriría compararlas aquí, sólo daré un par de opiniones concretas.

Diré que, en mi caso particular, una funcionalidad que tiene Google Docs en el caso de las hojas de cálculo y que, sólo por eso, hace que lo prefiera frente a la versión on-line de Excel, es la capacidad de convertir las hojas de cálculo en formularios para recogida de datos, con análisis básico automático de los datos recogidos. Excel Web App es una buena hoja de cálculo pero Google Spreadsheets va un paso más allá en cuanto a las aplicaciones prácticas que le puedes dar gracias a estos formularios. Esto, no obstante no deja de ser una mera anécdota para la mayor parte de los usuarios y si lo que buscas es una hoja de cálculo para usar como tal, ambas son buenas opciones, llevándole algo de ventaja Google debido a los addins de los que dispone. Además, para formularios prefiero Zoho Creator, que le da mil vueltas a Google Spreadsheets también.

Si estás acostumbrado a usar Office 2007/2010 y quieres una suite de ofimática gratuita y con toda la funcionalidad básica que generalmente necesita un usuario promedio, Office web Apps es una gran opción. Otra ventaja es que, desde luego, la compatibilidad con los formatos nativos de Office es mayor en el caso de Office web Apps que en Google Docs, y si es importante para ti que los documentos sean lo más parecidos a los originales cuando los subes desde el escritorio, entonces ahí también lleva ventaja.

Eso sí, un detalle que me gustaría destacar y que seguro que es fruto de polémica: ahora ya me parece bien que comparen Open Office con Microsoft Office… pero, eso sí, con Microsoft Office web Apps. En ese caso sí que podrían ser comparables de algún modo, desde luego mucho mas que cuando se compara Open Office con la suite completa de Office: es que no hay comparación posible. Sin embargo entre Open Office, Google Docs y Office WebApps, la cosa ya está más equilibrada..

¿Que me moje y de mi opinión?

Vale… Yo me quedo con Office de escritorio + DropBox, con un uso combinado de Google Docs + Office Web Apps + DropBox cuando no estoy en alguno de mis equipos 😉

Por fin está disponible el anexo a mi libro de ASP.NET 4.0. Se trata de un pequeño capítulo adicional que explica unos pequeños cambios que ha habido en la versión definitiva respecto a la funcionalidad de plantillas HTML enlazadas a datos de ASP.NET Ajax Library, en el capítulo 5.

Básicamente explica cómo obtener la última versión del código de Script y sacarle partido desde ASP.NET o desde cualquier otra tecnología (PHP, JSP, MVC o incluso HTML puro y duro), y los pequeños cambios en sintaxis que ha habido en un par de características en la versión final.

Puedes leerlo íntegramente gratis on-line en Scribd:

Tecnologías ASP.NET 4.0 – Anexo A – Enlazado a datos AJAX

Casi me pasa inadvertido, pero me acabo de dar cuenta de que este blog ha cumplido el pasado día 3 de Junio nada menos que ¡6 años! La verdad es que no está mal, y en Internet eso es mucho tiempo.

Es curioso ver cómo uno ha ido evolucionando junto con Internet.

Al final me he liado y he escrito, en un arrebato de nostalgia, mi evolución personal y cómo ésta ha ido acompasada con la de Internet en estos últimos 15 años.

Mediados de los ’90 – Páginas Web y papel, mucho papel

Antes de tener este blog, durante muchos años desde mediados de los noventa, tuve una página personal que colgaba del proveedor sevillano Arrakis, uno de los pioneros de Internet en España, y unos frikazos de cuidado pues el nombre de arrakis viene de las novelas de ciencia ficción Dune («Ni una sola gota de agua sobre la superficie de arrakis»).

La página se llamó durante muchos años «Visual Basic Extremo» y en ella me dedicaba a contar muchos trucos y técnicas avanzadas de Visual Basic, que era lo que se llevaba entonces. Eran tiempos más sosegados (aunque no más fáciles), mucho antes de .NET y la explosión verdadera de Internet. No tenía ni dominio propio.

Por aquel entonces empecé también a escribir en revistas del sector, en papel. En concreto en la tristemente desaparecida RPP (Revista Profesional para Programadores). Una joya con verdaderas virguerías de artículos que murió, en mi opinión, por tener artículos demasiado «cañeros» (la compraban cuatro frikis al final).

A finales de los 90 me dedicaba profesionalmente a escribir artículos, llegando a publicar hasta 4 o 5 por mes en diferentes revistas. Comía de eso y de consultoría y desarrollo a medida, así como de dar charlas y cursos.

Principios de siglo – Página Freeware, empresa y más papel

A primeros de 2001 me decidí a cambiar y creé este dominio JASoft.org, con un cambio de filosofía respecto a lo anterior para hacer la página mas dinámica y más orientada a software gratuito que yo creaba, pero con un estilo página personal todavía. Publiqué muchísimo software gratuito allí. Algunos de estos programas aún los tengo en este blog, aunque actualizados, y alguno llegó a tener mucho éxito. De todos modos seguía siendo una página personal al uso.

La evolución de los contenidos de este dominio se puede ver en la siempre útil Internet Wayback Machine. Es de flipar 🙂

También en esta época (Abril de 2000) fué cuando monté Krasis, con la que hemos cumplido 10 años hace poco. Seguí manteniendo colaboraciones con algunas revistas, sobre todo PC World y la recientemente desaparecida Windows TI Magazine, pero bajando un poco la cantidad de colaboraciones (2 artículos al mes) por que tenía que dedicar mucho más tiempo a la empresa.

Mediados de década – La era de los blog y menos papel

En 2004 no se oía hablar de otra cosa que de los blog. Aún estaban empezando pero ya era una tendencia imparable. Así que, tras las dudas iniciales sobre si sería una moda o no, en Junio de 2004 me lancé a ello de la mano de mi buen amigo Iván González y posterior compañero de fatigas, que llevaba entonces la comunidad de blogs Golem Project (ahora desparecida tristemente por el escaso apoyo de la institución que lo creó. De eso también aprendí).

El blog realmente da muchas facilidades que una página no tenía. Puedes mantener los contenidos sin esfuerzo y preocupándote sólo de ir metiendo nuevo material, sin los problemas y desvelos que daba mantener una página (además «a pelo», porque a mediados de los 90, cuando empecé con ella, un CMS no se sabía ni lo que era). Así que el blog realmente me dio muchas facilidades para contribuir y crear mucho contenido. Empecé a toda máquina y aquí sigo tantos años depues. Este fue el primer post del blog.

Mi nivel de colaboración con las revistas en papel bajó mucho. En aquella época empecé a colaborar también con DotNetMania. Actualmente sólo escribo 2 o 3 artículos al año en papel (este mes, por ejemplo, puedes ver un artículo mio sobre Visual Studio 2010 si te compras PC World en el kiosko). Mi tiempo no da para tanto y la verdad es que escribir para publicaciones on-line o en blogs me proporciona mayor impacto que con cualquier revista en papel, y lo puedo hacer mucho más a mi ritmo.

Además, poco después, en 2005, nació nuestro proyecto de formación on-line campusMVP. A través de él he creado muchísimo material formativo todos estos años: cursos, vídeos, demos… Y muchas otras personas se han unido al proyecto por el camino. A esto dedico gran parte de mi tiempo. Es una lástima que no vea la luz para todo el mundo, pero los frikis también tenemos que comer, así que no queda más remedio que cobrar por dar acceso a este material (por el momento y mientras no tenga una idea féliz que no sea la publicidad, por que la gente no pincha).

Final de década – Redes sociales y casi no hay papel

Y ahora, en 2010, estamos inmersos en el mundo de las redes sociales. He de reconocer que yo era de los que me resistía, sobre todo a una en particular: Twitter. De hecho entré a finales del año pasado todavía. Pero si los blog supusieron para mi una revolución a la hora de compartir con la comunidad técnica, Twitter está empezando a ser otra revolución también para mi.

Confieso que mi primera reacción a Twitter hace un par de años cuando empezó a sonar fue: «¿micro-blogging? ¿140 caracteres? ¿Estáis de coña? No tengo tiempo para esas memeces«. Al final me metí por la «presión social» que tenía, sobre todo de mis compañeros del The Monday Reading Club, a los cuales se lo agradezco. Y es que los de marketing son los que más están tirando del medio.

Lo cierto es que ahora donde más cosas pongo es en mi Twitter. Ya lo contaba hace unos meses en un post: Los tiempos están cambiando. A través de él voy posteando las cosas interesantes que me voy encontrando, ya que no todo tiene porque ser contenido original tuyo. El blog es más para crear, y Twitter es más para compartir. Twitter te permite además mantenerme al día más facilmente si escoges bien a qué gente seguir y si evitas a los pesados que están todo el día twitteando memeces, claro.

Tras haberlo estado usando más de medio año ahora lo encuentro indispensable. Y por supuesto cada vez que escribo algo en este blog también lo twitteo para que la gente se entere, por lo que ni siquiera es necesario pasarse por aquí para ver si hay algo nuevo.

Me llama mucho la atención que los técnicos, generalmente, somos los más reacios a adoptar este tipo de herramientas sociales. De hecho esta circunstancia me ha dado pie para escribir un artículo para una conocida revista (en papel) que verá a la luz en breve. Iba a ser un post para este blog pero la cosa ha ido creciendo y creo que quedará un artículo interesante. Ya os contaré en mi Twitter 😛

Mi consejo: si  no la tienes ya, hazte con una cuenta de Twitter y escoge bien a quien vas a seguir. Aunque tú no publiques nada y sólo «consumas». Y si encima te haces follower mío pues mejor que mejor 🙂 Mis twitts no son solo de programación, sino también de tecnología, mucho de Internet y tendencias, algo de marketing… Sólo cosas interesantes, eso sí, y alguna que otra opinión personal de vez en cuando.

En cuanto a mis colaboraciones en papel, se han reducido aún más si cabe. Prefiero dar charlas y conferencias, escribir en este blog o el blog de email marketing de Krasis. He diversificado, ya que ahora hablo también mucho de marketing y empresa. Son cosas de la edad. Además siguen estando ahí los libros. Desde que empecé con mi primer libro para Anaya Multimedia cuando tenía 24 25 años no ha pasado ningún año (a excepción de 2008) en el que no haya escrito algún libro, revisado una obra mía anterior para actualizarla o al menos haya colaborado en alguno con algún otro autor. Y es que eso sí que me puede. Los libros no dan dinero, pero sí que siguen siendo una gran fuente de satisfacción, sobre todo si se difunden mucho, como he tenido la suerte de experimentar con alguno de los que me han publicado. Además, ahora como la editorial es nuestra aún me gusta mas 🙂 Qué conste que mis anteriores editores han sido siempre una maravilla, y jamás me han tocado una coma de los textos que he enviado, y eso se agradece mucho.

2010 en adelante – ¿Quién sabe?

Y aquí estamos ahora: Twitter, Blog pero menos, papel pero mucho menos, libros en papel (y pronto electrónicos)…. Desde hace poco hasta tengo «mi página de gurú», que me da mucha vergüenza con vosotros, los técnicos, pero es que en otros ámbitos -más empresariales- tienes que «venderte» para que te paguen una conferencia. En el ámbito técnico ya hace muuuchos años que es imposible que nadie te pague por nada, y menos por una charla/conferencia/evento/webcast 😉 Una verdadera vergüenza pues parece que nuestro trabajo no se valora, pero en fin…

Tengo mucha curiosidad por saber qué estaré posteando (o twitteando o veteasaberque-ando) dentro de 2, 5 o 10 años. Quizá la vida me haya vencido ya, y haya mandado todo a paseo y ni me dedique a la tecnología. Quizá siga a tope, como ahora, pero usando sabe Dios qué medio esotérico, aún por inventar, para crear contenidos. ¿Grabaciones holográficas? ¿Un simple móvil del futuro con teclado virtual? ¿O quizá Google haya dominado el mundo ya y nos tenga a todos censurados para no criticarlos?

Quién sabe. Quédate por aquí para descubirlo y por el camino haré lo que pueda para ir aportando cosas, como hasta ahora.

Actualización 18/6/2010: Hoy he encontrado esta tira del bueno de Hugh MacLeod (os recomiendo su libro «Ignore Everybody», por cierto), y me he sentido identificadísimo X-DD

La caché de ASP.NET es una maravilla. Permite almacenar en memoria (o en otra ubicación, ya que es extensible) datos costosos de obtener y que no caduquen de inmediato. De esta forma las siguientes veces que debamos utilizarlos en la misma aplicación podremos obtenerlos desde la caché sin necesidad de volver a calcularlos o generarlos. Además la caché de ASP.NET ofrece un montón de características avanzadas que van más allá del simple almacenamiento. Por ejemplo podemos establecer caducidades de la información tanto en un determinado momento en el futuro, si no se utiliza tras un periodo, haciendo que unas informaciones dependan del valor de otras o creando dependencias de ciertos elementos externos (como un archivo, una consulta en la base de datos o una clave del registro).

Esto último es de especial interés, pues nos brinda la posibilidad de hacer cosas bastante complicadas sin apenas código. Por ejemplo, si nuestra aplicación depende de la información almacenada en un archivo en el disco duro, podemos leer sus contenidos, almacenarlos en caché e indicar que queremos que la caché caduque de inmediato en caso de que el archivo sea modificado externamente. Compáralo con el trabajo de conseguir lo mismo totalmente a mano.

Para abarcar toda la funcionalidad de la caché de .NET necesitaríamos un capítulo completo de un libro, y no es el objeto de este post. En MSDN tenemos acceso a toda la documentación al respecto.

El caso es que la versatilidad de la caché de ASP.NET ha hecho que muchos otros programadores quisieran usarla también en aplicaciones de escritorio y de otros ámbitos no atados a la Web. De hecho, en este mismo blog hablábamos hace más de 3 años de cómo conseguirlo. Lo que ocurre es que esto no dejaba de ser un apaño, y resultaba cuando menos extraño tener que añadir una referencia a System.Web.dll en nuestro proyecto. Incluso Microsoft/Avanade dentro de su Enterprise Library ha incluido siempre un módulo de caché para aplicaciones de escritorio con similares funcionalidades.

En .NET 4.0 la cosa se ha simplificado mucho. Se ha cambiado la implementación de la caché para que siga el modelo de proveedores (como en el resto de ASP.NET) para poder definir proveedores de caché propios y extender de diversas maneras la forma de almacenar la información. Y lo que más nos interesa para este post: se ha separado la implementación de la parte Web de la plataforma, para darle independencia y poder usarla en cualquier otro tipo de aplicación.

Ahora toda la funcionalidad de la caché se encuentra dentro del ensamblado System.Runtime.Caching y podemos hacer uso de uso clases desde cualquier tipo de aplicación, aunque hay algún truquillo que ahora mismo voy a contar.

Añadir una referencia a System.Runtime.Caching en una aplicación Windows Forms

Para probar cómo podemos usarla, vamos a crear un nuevo proyecto de Windows Forms en Visual Studio 2010. Lo primero que debemos tras haber creado el proyecto es añadir una referencia a System.Runtime.Caching, que nos habilitará el poder sacarle partido a la funcionalidad de caché.

Pulsamos con el botón derecho en el nodo del proyecto en el Explorador de Soluciones y elegimos la opción “Agregar Referencia”. Dentro de la pestaña .NET buscamos el ensamblado:

¡Eh! Un momento, ¿Qué pasa? No está en la GAC ¡Qué raro!

Es raro, pero no pasa nada. Vamos a buscarlo directamente en el disco duro, dentro de la carpeta de .NET en C:WindowsMicrosoft.NETFrameworkv4.0.30319. Ahí sí que está:

La añadimos, pero de repente observamos que en las referencias del proyecto aparece con una advertencia:

Si nos fijamos más, en la ventana de errores aparece un mensaje indicándonos que esa biblioteca no está preparada para trabajar con este perfil de .NET, y que la quitemos o que cambiemos el perfil.

¿Qué son los perfiles de .NET?

Un perfil de .Net es un subconjunto de la plataforma completa especialmente pensado para un tipo concreto de aplicación. En lugar de contener todas las funcionalidades de la plataforma ofrece sólo las interesantes para el perfil concreto con el que estemos trabajando. De esta forma si la aplicación típica de un determinado ámbito no necesita usar la funcionalidad completa de .NET puede usar sólo una parte y conseguiremos una descarga más pequeña del runtime de la plataforma. Un buen ejemplo son las aplicaciones Windows: ¿para qué vamos a distribuir con ellas todas las DLLs de la plataforma si en realidad no van a usar nada de la parte Web o la de Silverlight?. Esta funcionalidad está relacionada con la capacidad Multi-targeting de Visual Studio y ya apareció con la versión anterior en VS2008.

En Visual Studio 2010, por defecto, las aplicaciones de Windows Forms utilizan uno de estos perfiles, en concreto el denominado .NET Framework 4.0 Client Profile. Éste no incluye System.Runtime.Caching entre los ensamblados que puede utilizar, de ahí la advertencia, ya que luego en tiempo de ejecución en otra máquina puede que no estuviera disponible.

En este excelente post de Jossef Goldberg, del equipo de .Net en Microsoft, se explica la composición exacta de este perfil, qué funcionalidad contiene y cómo se compara con el mismo en .NET 3.5. También puedes ver qué ensamblados contiene el perfil viendo su definición en tu disco duro, en la ruta C:Program FilesReference AssembliesMicrosoftFramework.NETFrameworkv4.0ProfileClient. Finalmente puedes descargar el instalador de este perfil de la plataforma desde la Web de Microsoft.

Vale, ahora que ya sabemos qué es un perfil ¿cómo evitamos que se produzca la advertencia anterior?

Si vamos a las propiedades del proyecto Windows Forms, dentro de su pestaña “Application” tenemos un apartado para elegir contra qué versión de la plataforma queremos trabajar. Si desplegamos la lista podemos cambiar desde la versión cliente a la versión completa de la plataforma que es la inmediatamente anterior:

Al hacerlo y aceptar se nos avisa de que el proyecto tiene que cerrarse y volver a abrirse para poder realizar los cambios. Una vez hecho si vamos a agregar una referencia a la funcionalidad de Caching veremos que ahora sí está disponible desde la GAC, al ser la plataforma completa:

¡Listo!

Ahora ya podemos sacarle partido a la misma funcionalidad de caching que tendríamos en ASP.NET.

He dejado una pequeña descarga (ZIP, 14KB) con un ejemplo muy simple de uso para que se vea que realmente funciona sin problemas.

Sólo un detalle importante a tener en cuenta: la caché es privada para cada dominio de aplicación, por lo que sólo se puede acceder a la misma desde la propia aplicación que la ha creado. Esto es lógico por seguridad, pero alguien podría pensar que se podría compartir entre aplicaciones distintas o que si ejecutamos dos veces la misma aplicación tendríamos acceso a los mismos datos de caché. No es así y los datos almacenados sólo nos servirán dentro de ventanas o módulos que se ejecuten en la misma aplicación.

Imagino que se podría escribir una implementación propia de una caché que se saltase esos controles de algún modo, pero no es el verdadero objeto generalmente de este tipo de almacenamiento.

¡Espero que te sea útil!