Una de las cosas más reseñadas de ASP.NET 2.0 es que es capaz de gestionar páginas ASPX creadas en diferentes lenguajes todas al mismo tiempo. Es decir, puedes tener una página o un control escritos en C# y mezclarlos con otros escritos en VB.NET o J# sin problema. Incluso puedes depurarlos todos juntos desde Visual Studio, saltando sin problemas de un lenguaje a otro. Ahora bien, desde mi punto de vista esto no es demasiado interesante. Es raro que reutilices una página de una aplicación a otra y si escribes una aplicación completa desde cero normalmente lo haces en el mismo lenguaje. Hombre, pensando en equipos de desarrollo donde varios programadores contribuyen al mismo proyecto y trabajan en lenguajes distintos es muy interesante, pero vamos... Normalmente lo que compartes entre aplicaciones son controles o bibliotecas de funciones, las cuales normalmente deberías compilar en sus propios ensamblados y listo. Ya no tendrías que mezclar lenguajes ahí. Otra posibilidad es que teng... [Más]

Siguiendo a mi post anterior, vamos a ver una técnica alternativa para conseguir la persistencia del ViewState en sesión. La anterior técnica, nativa de ASP.NET 2.0 adolecía de varios problemillas, los más importantes son: 1.- No eliminaba del todo el ViewState, sólo una parte del mismo. En formularios Web con muchos controles el tamaño del ViewState sigue siendo considerable, si bien se reduce bastante. 2.- Sólo funciona en ASP.NET 2.0, pero no en versiones anteriores. Voy a explicar a continuación una técnica alternativa que elimina estos problemas y tiene algunas ventajas a mayores. Para conseguir manejar a nuestro antojo el ViewState podemos sobrescribir dos métodos importantes de la página: SavePageStateToPersistenceMedium y LoadPageStateFromPersistenceMedium. Como se deduce de su propio nombre estos métodos se llaman automáticamente por la infraestructura de páginas A... [Más]

El ViewState de una página ASP.NET 2.0 es lo que permite la "magia" de los PostBack. Se trata de un campo oculto que se envía con el formulario que introduce ASP.NET en todas las páginas ASPX y contiene información sobre el estado de los controles de la misma. A partir de él se recupera dicho estado y parece que la página funciona como un formulario de escritorio tradicional. El caso es que si tenemos muchos controles este ViewState puede llegar a ocupar mucho y eso hace que cada PostBack al servidor sea muy lento y se empiece a notar demasiado. En casos un poco extremos podemos tratar de minimizar este trasiego de información entre cliente y servidor persistiendo el ViewState en otro lugar en lugar de en un campo oculto de la página. Para ello ASP.NET 2.0 ofrece "de serie" un objeto especial llamado SessionPageStatePersister que permite conseguir precisamente ese efecto y qeu el ViewState se conserve en la memoria del servidor. Para ello lo único que hay que hacer es sobreescribir ... [Más]

Este es un tema que me traía de cabeza durante varios días y que no lograba solucionar. Resulta que hemos colocado una aplicación Web en un servidor Windows 2003 de un cliente. En el directorio raíz de la aplicaicón había un par de archivos .exe que estaban ahí para ser descargados desde un enlace directo. Al intentar descargarlos desde Internet Explorer se quedaba el diálogo "flipado" mientras ponía "Obteniendo información del archivo...", y la descarga no comenzaba jamás. La configuración del servidor no tenía nada raro. Sólo lo habitual en un IIS, así que no encontraba explicación. Además ocurría en TODOS los IE y en todas sus versiones (incluyendo la última que acaba de salir, la 7), así que no era un problema puntual por un index.dat corrupto o cosas típivcas similares. Un verdadero misterio. El misterio aumentaba cuando veías que con otros navegadores (por ejemplo Firefox) los archivos bajaban sin problemas y se guardaban. Incluso si veías el tráfico que se generaba con un mon... [Más]

¡Ya era hora! Seguro que a estas alturas ya lo sabes,pero por si acaso.... Desde hoy mismo ya está disponible para descarga la versión definitiva de Internet Explorer 7. ¡OJO!: de momento sólo está disponible en inglés. En los próximos días lo estará en castellano y otros idiomas. De todos modos ya puedes probar tus aplicaciones con la versión definitiva y ver si funcionan. Ten cuidado ya que hay bastantes cambios, sobre todo en lo referente a la seguridad, aunque también en otros aspectos. Lo mejor es que revises el Readiness Toolkit for Developers que te muestra todos los cambios y como afectan a tus aplicaciones, ofreciendo alternativas.

Gran trabajo el que está haciendo Microsoft con sus herramientas de diseño para desarrollo. En concreto me ha encantado el nuevo editor para la Web que va a sustituir a FrontPage y que, con todo lo que tiene, sustituye sin problemas también a productos de la competencia como Macromedia Dreamweaver. Se trata de Expression Web Designer, que ahora está por la Beta 1. Vale la pena instalarlo y probarlo. Por lo que he podido comprobar estos días mientras lo probaba en mis escasos ratos libres, se trata de un producto muy estable a pesar de ser una Beta, funciona muy rápido en un ordenador normalito (yo tengo un Pentium IV a 1,7 y 512 MB de RAM como equipo de pruebas y va como un rayo), y lo único que necesitas es tener instala la plataforma .NET 2.0. Al contrario de lo que estábamos acostumbrados hasta ahora con las herramientas de diseño Web de Microsoft (yo personalmente siempre he odiado FrontPage), Expression trae todo lo que un diseñador y programador pudiera desear. De hecho tiene c... [Más]

Bueno, al final he tardado un poco más de lo que pensaba en sacar algo de tiempo para poner una segunda parte del anterior "post" sobre eventos y monitorización de aplicaciones (y ahora no es que tenga mucho tiempo tampoco), pero es que con el lanzamiento del "Pack Certificación" he estado realmente liado... Bien, sigamos... Para configurar elementos de notificación en nuestra aplicación Web ASP.NET 2.0, sólo tenemos que incluir algunos parámetros en el archivo de configuración de la misma, bajo el nodo <healthMonitoring>. De hecho ASP.NET 2.0 ya viene con algunos de ellos preconfigurados y funcionando. Por ejemplo, todos los errores no gestionados que se produzcan en la aplicación quedan automáticamente guardados en el registrode eventos del sistema, sin que tengamos que hacer nada especial: Esto es de extrema utilidad porque en caso de producirse un error en la aplicación que no hayamos controlado no tenemos que preocuparnos de pedirle a los usuarios que nos guarden los d... [Más]

Este tema siempre me ha encantado: la monitorización de tus aplicaciones para ver si se están comportando como es debido o no. Esto en su sentido más amplio incluye todo tipo de información: desde contadores de operaciones y rendimiento personalizados hasta gestión automática de notificaciones ante ciertos sucesos y registro de todo lo importante que haya. La API de ASP 3.0 que usábamos en Krasis ya tenía integrado un sistema de Log automático y explotación del mismo, así como algunas utilidades para gestionar errores de forma automática. En .NET la cosa mejora mucho porque podemos crear contadores de rendimiento personalizados y crear facilmente entradas en el registro de sucesos del sistema. En ASP.NET 2.0 los chicos de Microsoft se han superado también en este aspecto introduciendo lo que se ha dado en llamar "ASP.NET 2.0 Health Monitoring" o lo que yo llamaría en castellano a falta de una traducción mejor "Servicios de notificación y registro de ASP.NET 2.0". El sistema ofrece,... [Más]

Bueno, esta es una de esas cosas que pueden volver loco a uno antes de encontrar el motivo que lo está provocando. Supón que tienes una aplicación Web que funciona de maravilla y que utiliza algunas variables de sesión para guardar datos del usuario (por ejemplo un identificador o cualquier otra cosa). Colocas la aplicación en producción en un servidor Windows 2003 Server y todo parece ir perfecto. El servidor es IIS 6.0 y la aplicación está escrita en ASP.NET 2.0. A medida que la cantidad de peticiones y usuarios crece la aplicación funciona de maravilla y se comporta muy bien, gestionando muchas peticiones por segundo sin problema hasta que de repente un día tienes una llamada... "Disculpe, soy un usuario de su aplicación y me hoy me ha pasado una cosa muy rara. He entrado con mi clave y nada más hacerlo me han aparecido los datos de otra empresa que no es la mía. Es como si se nos hubiesen cruzado las líneas. ¿no le estará pasando esto a alguien más y verán mis datos, verdad?" ... [Más]

El bueno de Scott Guthrie (del equipo de desarrollo de ASp.NET) puso ya hace tiempo un post muy bueno sobre porqué era muy recomendable (si no casi indispensable) poner un nombre dentro de web.config dentro de la configuración de los proveedores (tanto de Membership como de Roles, etc...). El motivo es que si no lo hacemos, al mover la aplicación no seremos capaces de acceder a los datos que hay en la base de datos pues casi seguro que hemos cambiado la ruta de la aplicación respecto al servidor de desarrollo, y es muy desagradable :-( Hoy me ha surgido una pregunta relacionada con esto y aprovecho la ocasión para recordarlo a todos los lectores de este blog desde aquí. Así que léete el post completo de Scott y ya sabes: que no se te olvidé nunca más :-)