IDisposable Thoughts

ViewStateHandlers is up!

cristian — Mon, 13 Jul 2009 14:19:35 -0600

Algunos recordaran mi corta serie de artículos acerca del manejo del ViewState en aplicaciones webforms ASP.NET, también recordaran que hay muchas pero muchas maneras de manejar el “ViewState” y que algunas son fácilmente reutilizables.

Me llamó la atención el correo que recibí un tiempo después de conversar acerca del uso de los PageAdapters:

Me preguntaba entonces dónde está la reutilización de código cuando usamos tu código para hacer más pequeño el ViewState.

Como recordaran algunos fragmentos de código son tomados de otras personas (como por ejemplo, el de enviar el ViewState hacia el fondo de la página que mencionamos en un artículo pasado), así que decidí hacer una librería que nos permitiera algo así como “manejar” de forma fácil y sencilla el ViewState en las Webforms, fue entonces cuando nació el ViewStateHandler library.

Esta librería pretende ser un simple contenedor de opciones para el manejo del ViewState, aún está en pañales pero ya tengo algo de código arriba en el control de versiones de CodePlex, si estan interesados pueden darle una hojeada!.

ViewStateHandlers en Codeplex

NOTA: Por el momento si quieren hecharle una hojeada al código, deben irse a la tab de “Source Code” en la página de proyecto de Codeplex. Falta mucho por escribir aún (terminar el código, escribir algo de documentación de como usarlo).

Stream Transformations

cristian — Sun, 05 Jul 2009 01:51:43 -0600

Recuerdo que una de las primeras cosas que solíamos aprender con un lenguaje o framework era el cómo leer/escribir de o hacia un archivo (o por lo menos antes así era). En la .Net Framework tenemos todo un namespace dedicado a las operaciones de E/S de datos e información (System.IO). Una de las clases básicas en este namespace es la clase abstracta Stream. Cómo en la mayoría de lenguajes y frameworks modernas, Stream encapsula o abstrae las operaciones de E/S hacia diversos orígenes y/o destinos, de esa manera tenemos cosas como Network Streams, File Streams, Memory Streams, etc…

Algo de lo cual no muchos nos habíamos percatado es que las clases derivadas de Stream no solamente abstraen operaciones de E/S, sino que también pueden ser usadas para “transformar” datos sobre la marcha, de esa manera tenemos ya en la .Net framework clases Stream especiales como GzipStream (Compresión/Descompresión), CryptoStream (Encriptación) y me imagino que hay muchas más en la framework. Hace ya varios meses leí en la MSDN Magazine (una de mis magazines favoritas por cierto, les recomiendo a todos suscribirse :P) un excelente artículo sobre Testing Transformation Streams (TS de aquí en adelante) y en general de que se trataba una TS y como crearla/utilizarla. Un ejemplo típico de una transformation Stream es una que elimine los espacios en una Stream básica, por ejemplo:

using System.IO;
using System.Text;
using System.Text.RegularExpressions;

namespace FilterSpacesStream
{
    public class NoSpaceStream : Stream
    {
        public NoSpaceStream(Stream sink)
        {
            Sink = sink;
        }

        private Stream Sink { get; set; }

        public override bool CanRead
        {
            get { return true; }
        }

        public override bool CanSeek
        {
            get { return Sink.CanSeek; }
        }

        public override bool CanWrite
        {
            get { return true; }
        }

        public override long Length
        {
            get { return Sink.Length; }
        }

        public override long Position
        {
            get { return Sink.Position; }
            set { Sink.Position = value; }
        }

        public override void Flush()
        {
            Sink.Flush();
        }

        public override long Seek(long offset, SeekOrigin origin)
        {
            return Sink.Seek(offset, origin);
        }

        public override void SetLength(long value)
        {
            Sink.SetLength(value);
        }

        public override int Read(byte[] buffer, int offset, int count)
        {
            return Sink.Read(buffer, offset, count);
        }

        public override void Write(byte[] buffer, int offset, int count)
        {
            string text = Encoding.UTF8.GetString(buffer);
            string result = Regex.Replace(text, @"\s", string.Empty);

            byte[] data = Encoding.UTF8.GetBytes(result);
            Sink.Write(data, 0, data.Length);
        }
    }
}

Y su respectivo Fact Fixture:

using System.IO;
using System.Text;
using Xunit;

namespace FilterSpacesStream
{
    public class NoSpaceStreamFacts
    {
        private readonly MemoryStream output = new MemoryStream();
        private readonly NoSpaceStream sut;

        public NoSpaceStreamFacts()
        {
            sut = new NoSpaceStream(output);
        }

        [Fact]
        public void It_can_read()
        {
            Assert.Equal(output.CanRead, sut.CanRead);
        }

        [Fact]
        public void It_can_write()
        {
            Assert.True(sut.CanWrite);
        }

        [Fact]
        public void It_can_Seek()
        {
            Assert.Equal(output.CanSeek, sut.CanSeek);
        }

        // And many other operations I really don't want to test...

        [Fact]
        public void When_write_a_string_with_spaces_it_returns_a_string_without_spaces()
        {
            string text = "This is a test ";
            byte[] buffer = Encoding.UTF8.GetBytes(text);
            sut.Write(buffer, 0, buffer.Length);
            sut.Flush();

            buffer = output.ToArray();
            string converted = Encoding.UTF8.GetString(buffer);
            Assert.Equal("Thisisatest", converted);
        }
    }
}

Uno de los usos básicos que podríamos darle a las Transformation Streams es crear una que sobre la marcha me comprima/cambie/elimine datos en la Render Stream utilizada por la ASP.NET Framework, ven ahora hacia dónde estoy orientando este post? (Rayos, creo que pensé en “voz” alta :P)

Bueno, hasta la siguiente entrega!

MVP Awarded

cristian — Fri, 03 Jul 2009 13:06:18 -0600

No sé porqué no lo había posteado antes, pero el día 1 de Julio recibí el siguiente mail en mi inbox:

Estimado/a Cristian Prieto,
Enhorabuena. Nos complace presentarle el programa de nombramiento MVP de Microsoft® de 2009. Este nombramiento se concede a los líderes excepcionales de la comunidad técnica que comparten de forma activa su experiencia de alta calidad y de la vida real con otras personas. Le agradecemos especialmente la contribución que ha realizado en las comunidades técnicas en el área de ASP/ASP.NET a lo largo del pasado año.

Claro, esa es la versión “genérica” de un mail diciéndote que este año has sido galardonado como MVP, así que todo indica que ahora soy MVP en ASP.NET. Gracias a cada uno de ustedes, los que día a día han tenido que soportarme durante mis charlas, escuchar y aguantar mis quejas sobre que X ó Y no funciona como debería o sobre cómo debería hacerse el procedimiento X. Ahora más que nunca me dieron unas ganas increíbles de cooperar con la comunidad, ahora más que nunca creo que debemos instar más a la gente a mejorar con cada día, ahora más que nunca me siento en deseos de transformar a Morts en Elvis.

Gracias a todos, gracias amigos…

Visual Studio Debugger, Mensajes y Tracepoints

cristian — Thu, 02 Jul 2009 13:13:35 -0600

Hace un tiempo conversaba con alguien acerca de como encontrar/resolver/debuggear errores en una aplicación legacy, y en base a eso surgió una conversación la cual al final terminó mal (o sea, me dejó personalmente con muy mal sabor de boca).

Yo no necesito un debugger, con un simple var_dump o print_r puedo ver el contenido de mis variables en el momento y me doy cuenta si estoy bien o estoy mal

Hace unas cuantas horas, conversando con otro amigo sobre Test Runners me dijó una frase que obviamente era chiste: “if you don’t have a good test runner you can use Console.WriteLine”

Aunque parezca increíble a veces, el imprimir un mensaje en algún lugar (Debugger, Consola, Log, etc) también podría ser una forma de debugging, el problema es que la mayoría de veces nos vemos obligados a modificar el código fuente de nuestro programa para lograrlo. De tal manera, tomemos en consideración la siguiente pieza de código:

using System;
using System.Diagnostics;

namespace ConsoleApplication1
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Debug.WriteLine("** Start **");
            var cat = new Cat();

            int number = 1;
            
            cat.Groom(number);

            Trace.WriteLine("** End **");
            
            Console.ReadLine();
        }
    }
}

Pongamos atención a la línea 10 y 17. Cuando ejecutamos nuestro código veremos en la ventana de Output del Visual Studio (el panel Debug) varios mensajes, pero entre esos la línea “** Start **” y “** End **”. A simple vista podríamos decir que ambos hacen exactamente lo mismo, pertenecen al mismo Namespace [System.Diagnostics] (de hecho si revisas sus métodos tienen las mismas signatures y los mismos métodos) pero difieren en la forma en que operan

Debug emite mensajes en design time, o sea, cuando la aplicación corre en modo Debug
Trace emite mensajes en runtime y siempre, o sea, cuando la aplicación este en modo Debug y modo Release

Obviamente cuando corremos la aplicación dentro del Debugger de Visual Studio, tanto las salidas de Debug y Trace son redireccionadas y mostradas en el panel de Debug de la Output Window, pero podemos redirigir esas salidas a un archivo (mediante los listeners de System.Diagnostics) o también se mostraran en la Trace de ASP.net, también puedo ver mensajes Trace “in-vivo” en la aplicación de forma simple, pero eso lo dejo para otro tip corto más adelante.

Como les mencionaba, los mensajes tipo Trace y Debug son usados para mostrar información relevante a la aplicación y que “teóricamente” debemos mostrar en momentos de debugging, no un “vamos a poner la app a producción, haz un search/replace para quitarle los mensajes de Trace”, o bueno, imagínense que es durante esa sesión de debugging y necesitas ver cierta información. Bien, así como hay Breakpoints tenemos Tracepoints que nos pueden mostrar mensajes en sesiones de Debugging, basta con insertar un breakpoint y en el menú contextual seleccionar “When Hit…” (observen que el ícono de breakpoint cambia a un rombo rojo).

Observen que puedo mostrar no solo expresiones, o variables encerrándolas con llaves, sino también variables “especiales” como el proceso, la Callstack, etc…

Los Tracepoints obedecen a las mismas reglas que un Breakpoint, son como hermanos o como un “breakpoint” especial que indica mensajes, aunque claramente si le quitamos el check en “Continue Execution” se comportará como un breakpoint, sólo que mostrará un mensaje en output como “adición especial” (y cambiará su ícono mostrando que es un breakpoint, no un tracepoint).

Saludos y hasta la próxima entrega!

Visual Studio Debugger, Conditional Breakpoint

cristian — Wed, 01 Jul 2009 11:50:32 -0600

Se pueden agregar condicionales a los breakpoints, de esta manera entraremos en el breakpoint solamente si la condición es satisfecha.

Por ejemplo, podríamos decirle que haga un breakpoint si la variable number es mayor a 2 (Si observan bien el indicador de breakpoint cambia para mostrar que tiene incluida una condición).

Otra opción importante son los filtros de Breakpoint, los cuales limitan el breakpoint a procesos, máquinas o thread específicas de ejecución. Son bastante útiles para el debugging de aplicaciones multithread o de múltiples procesos.

Hay que poner especial atención a los tooltips que aparecen sobre los indicadores de Breakpoints, porque nos muestran las condiciones o filtros bajo los que se encuentra el breakpoint.

Visual Studio Debugger, Breakpoints

cristian — Wed, 01 Jul 2009 11:32:53 -0600

Creo que luego de aprender el F5 (Debug), Ctrl + F5 (Run without debugging) y Shift + F5 (Stop Debugging) lo siguiente que uno aprende al utilizar el Debugger de Visual Studio es el uso de los breakpoints. Según Wikipedia un Breakpoint es una pausa o stop intencional dentro de un programa con propósitos de debugging, el propósito es más que pausarlo, porque durante esa “pausa” el developer puede examinar la memoria y condiciones de ejecución actuales de su programa, de forma en que pueda observar que se esta comportando como espera.

En Visual Studio Debugger es sumamente fácil insertar un Breakpoint, como recordaremos en Visual Studio el Debugger esta integrado íntimamente con el Editor, de tal manera que operaciones como las de “Insert breakpoint here” son sumamente sencillas. Para insertar un Breakpoint basta con hacer un click en el margen derecho del punto de edición y listo, una “bolita roja” mostrará el punto del breakpoint.

Navegando entre Breakpoints es sumanente sencillo, Cada vez que llegamos a un método podemos ver que sucede dentro de él con un Step Into (F11), Si entramos a un método y ya no deseamos ver que esta pasando, podemos salir de el usando un Step Out (Ctrl + F11), y si queremos saltarnos los detalles de ejecución de un método usamos Step Over (F10). Podemos continuar la ejecución normal o ir hasta el siguiente breakpoint usando Continue (F5). Podemos reiniciar la ejecución del programa con Restart (Ctrl + Shift + F5).

Podemos insertar un breakpoint desde “código” (Útil a debuggear cosas como Windows Services), basta con usar System.Diagnostics.Debugger.Break()

using System;
using System.Diagnostics;

namespace ConsoleApplication1
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Console.WriteLine("** START **");
            var cat = new Cat();


            Debugger.Break();
            int number = 1;
            
            cat.Groom(number);

            Console.WriteLine("** END **");
            Console.ReadLine();
        }
    }
}

Visual Studio Debugger, Anuncio

cristian — Fri, 26 Jun 2009 11:17:38 -0600

Desde hace ya varias semanas que viene una idea resonando en mi cabeza, una serie (probablemente corta, quien sabe) acerca del bueno uso o tips de debugging en ese nuestro amigo el Debugger de Visual Studio.

Alguien me comentará: “Hey, pero ahí si te pasaste de básico compadre, yo quiero algo mas ‘avanzado’, quizás háblanos de .Net 4.0 o de las lunas de Marte [si, Marte tiene 2 lunas]”

Una de las cosas que disfruto de sobremanera es el metoring en equipos de desarrollo, y algo que me he topado en todos estos años de trabajo en grupos es el detalle del poco conocimiento que tienen los developers acerca de las herramientas que usan en su día a día, una de ellas, el Debugger. Es fantástico todo lo que podemos llegar a conocer de nuestra aplicación si aprendemos a usar correctamente el debugger.

Recuerdo una discusión hace un tiempo con alguien que me mencionaba: “Yo nunca he necesitado ni usado un debugger en mi lenguaje X ó Y, no es necesario, es overrated”. Luego este mismo individuo nos explicaba como usaba técnicas novedosas como “Print lavariable” para ver el contenido de la variable en un punto. ¿Increíble verdad?

Desarrollando en .Net encontramos dos debuggers importantes, WinDBG, el padre de todos los debuggers en la plataforma Windows, con el cual es posible hasta debuggear al mismo Windows u operaciones de kernel de Windows (útil para cosas como crear device drivers o similares). Comprender el WinDBG y todo lo que podemos hacer con el es algo extenso, así que nos concentraremos en un hermano menor (no relacionado directamente) y que viene en nuestro amigo inseparable Visual Studio, El Visual Studio Debugger.

Hasta el siguiente post

Disminuyendo el ViewState, Moviéndolo al fin de página

cristian — Wed, 24 Jun 2009 21:37:48 -0600

Cuando pensé que se me habían olvidado los temas para seguir hablando del ViewState me encuentro con la siguiente idea: Moverlo al final de la página y así acelerar la carga de la página HTML en el Browser. El artículo original se encuentra en el blog del increíble Scott Hanselman por si quieren revisarlo.

Bien, la idea de Hanselman es sumamente simple, captamos el evento Render de la página y la modificamos extrayendo el ViewState actual, removiendolo y volviendo a agregarlo al final antes de la tag </form> de la form principal. Hanselman hace la anotación que con este approach no podemos tener más de una form en la página.

using System.IO;
using System.Web.UI;
using System.Web.UI.Adapters;

namespace ViewStateSample.Web
{
    public class BottomViewStatePageAdapter : PageAdapter
    {
        protected override void Render(HtmlTextWriter writer)
        {
            var sw = new StringWriter();
            var htmlWriter = new HtmlTextWriter(sw);

            base.Render(htmlWriter);

            string html = sw.ToString();

            int startPoint = html.IndexOf("<input type=\"hidden\" name=\"__VIEWSTATE\"");
            if (startPoint >= 0) {
                int endPoint = html.IndexOf("/>", startPoint) + 2;
                string viewStateInput = html.Substring(startPoint, endPoint - startPoint);
                html = html.Remove(startPoint, endPoint - startPoint);

                int formEndStart = html.IndexOf("</form>");
                if (formEndStart >= 0)
                    html = html.Insert(formEndStart, string.Format("\n{0}\n", viewStateInput));
            }

            writer.Write(html);
        }
    }
}

Obviamente debido a que es un PageAdapter necesitamos usar a nuestro viejo amigo el Browser File

<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="System.Web.UI.Page"
               adapterType="ViewStateSample.Web.BottomViewStatePageAdapter" />
    </controlAdapters>
  </browser>
</browsers>

Claro que para lograr una verdadera optimización es necesario también mover campos como el __EVENTVALIDATION y tomar en cuenta casos en que se encripta el ViewState.

Algo interesante es como implementar esta clase con nuestra __COMPRESSIONSTREAM, pero esto se los dejo de investigación para el lector.

Comprimiendo el ViewState, usando el Browser File

cristian — Tue, 23 Jun 2009 13:26:31 -0600

NOTA: El código anterior no fue probado en mi máquina, gracias a Ricardo por indicarme el error. Reescribo parte del post con las aclaraciones y con el código corregido.

Uno de mis lectores me escribió el día de hoy con un problema específico acerca de mi post sobre usar el Browser File para reutilizar nuestros cambios en la compresión del ViewState:

Tratando de usar el browser file con el page adapter de compresión me fue imposible debido a que me solicita que el control debe ser un control adapter

Bien, la falta, para variar, fue mía. No indiqué en el ejemplo los cambios que se necesitan. Lo bueno es que son pequeños cambios!

Para que funcione el browser file con controles necesitamos indicar un “Control Adapter”, en nuestro caso ya que es un Page Control necesitamos usar un PageAdapter
el PageAdapter tiene una propiedad Page que se refiere a nuestra Page la cual estamos “adaptando”
El PageAdapter no posee un overload equivalente al SavePageToPersistentMedium
El PageAdapter posee un overload (GetStatePersister) para retornar el PageStatePersiter que luego será usado en vez del PageStatePersister de la página
Podemos adaptar nuestro ViewState comprimido creando un PageStatePersister

Manos a la obra, lo primero es adaptar nuestros métodos SavePageStateToPersistenceMedium y LoadPageStateFromPersistenceMedium a un PageStatePersister, para esto podemos heredar de PageStatePersister. Ojo, el PageStatePersister es responsable de guardar tanto el ControlState como el ViewState, ambas son guardadas en una estructura tipo Pair.

using System;
using System.IO;
using System.Text;
using System.Web.UI;
using Rioshu.Utils.Compression.SevenZip;

namespace ViewStateCompressCS
{
    public class HiddenFieldCompressedViewState : PageStatePersister
    {
        public HiddenFieldCompressedViewState(Page page) : base(page)
        {
            Formatter = new LosFormatter();
        }

        public LosFormatter Formatter { get; set; }

        public override void Load()
        {
            string viewState = Page.Request.Form["__COMPRESSSTATE"];
            if (string.IsNullOrEmpty(viewState))
                throw new InvalidOperationException("Something is wrong with the current compressed ViewState");

            byte[] vstateBytes = Convert.FromBase64String(viewState);
            vstateBytes = SevenZipHelper.Decompress(vstateBytes);
            viewState = Encoding.UTF8.GetString(vstateBytes);
            var pair = Formatter.Deserialize(viewState) as Pair;
            if (pair == null)
                throw new InvalidOperationException("Something is wrong deserializing the current compressed ViewState");

            ViewState = pair.First;
            ControlState = pair.Second;
        }

        public override void Save()
        {
            string viewState = string.Empty;
            using (var sw = new StringWriter()) {
                Formatter.Serialize(sw, new Pair(ViewState, ControlState));
                viewState = sw.ToString();
            }

            byte[] vstateBytes = Encoding.UTF8.GetBytes(viewState);
            vstateBytes = SevenZipHelper.Compress(vstateBytes);
            viewState = Convert.ToBase64String(vstateBytes);

            Page.ClientScript.RegisterHiddenField("__COMPRESSSTATE", viewState);
        }
    }
}

Bien, ahora simplemente escribimos el PageAdapter necesario

namespace ViewStateCompressCS
{
    public class CompressedViewStatePageAdapter : System.Web.UI.Adapters.PageAdapter
    {
        public override System.Web.UI.PageStatePersister GetStatePersister()
        {
            return new HiddenFieldCompressedViewState(Page);
        }
    }
}

Por último, modificamos nuestra clase base de la página para que simplemente haga lo que le corresponde

using System;
using System.Web.UI;

namespace ViewStateCompressCS
{
    public partial class _Default : Page
    {
        protected void Page_Load(object sender, EventArgs e) {}
    }
}

Casi listo, simplemente nos hace falta agregar el Browser file

<browsers>
  <browser refID="Default">
    <controlAdapters>
      <adapter controlType="System.Web.UI.Page"
               adapterType="ViewStateCompressCS.CompressedViewStatePageAdapter" />
    </controlAdapters>
  </browser>
</browsers>

Listo, ya podemos reutilizar nuestros cambios como si nada. El código esta basado en el código base del artículo “Exprimiendo la compresión”

Debug Tip #2: Internet Explorer Javascript debug con Visual Studio

cristian — Tue, 23 Jun 2009 00:37:25 -0600

Hace muchos años, cuando no conocía lo lindo de Visual Studio y sus pormenores, cuando no teníamos Javascript frameworks como JQuery, Dojo, cuando no existían herramientas como la Internet Explorer Developer Toolbar o Fiddler, cuando Firebug en Firefox era una extensión en pañales y el debugger de javascript era Venkman Debugger. En esos tiempos remotos la mayor pesadilla de un developer era encontrarse con un rebelde script de javascript que no funcionara correctamente en Internet Explorer, cuando nos encontrábamos con la necesidad de debug javascript en Internet Explorer.

Muchos web developers aún hoy en día (y aún aquellos especializados en tecnologías Microsoft) desconocen el poder de Visual Studio para debuggear nativamente scripts de Javascript en Internet Explorer. Al igual que su contraparte el debugger de SQL Server, este se integra transparentemente a la experiencia de debug de Visual Studio.

Comencemos con una simple página HTML dentro de un proyecto de Visual Studio (en mi caso un Web Application Project).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title></title>
    <script language="javascript" type="text/javascript">
        function sayHello(person) {
            alert("Hello " + person);
        }
    </script>
</head>
<body>
    <input type="button" id="simple_button" onclick="sayHello('friend')" value="Say Hello" />
</body>
</html>

Lo ejecutamos con nuestro querido amigo F5 (Run) de Visual Studio y al presionar el boton, voilà! el mensaje que esperábamos. Preparemos el Internet Explorer para la experiencia de Debugging, por defecto no esta habilitado para debug de scripts, pero basta con ir a Tools –> Internet Options –> Advanced y quitar los checks en las casillas que desabilitan el script debugging

Ahora regresamos a la página en cuestión y agregamos a un siempre amigo Breakpoint

Nuevamente ejecutamos nuestra web application y al ir a la página y presionar el botón, shazam!

Debug instantáneo con call stack y todo para Javascript :P

Encryptando el ViewState

cristian — Mon, 22 Jun 2009 20:04:31 -0600

Como recordaran el ViewState es una simple Property Bag (con tracking changes support claro) en la cual podemos meter cualquier dato u objeto serializable que necesitemos. En otras palabras es posible hacer algo como esto

using System;
using System.Web.UI;

namespace WebApplication11
{
    public partial class _Default : Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            ViewState["data"] = "hola mundo";
        }
    }
}

Y claro, en este caso “hola mundo” será guardado en el ViewState por defecto renderizandose en el campo __VIEWSTATE de la página en el browser cliente. Cómo el formato de serialización es conocido (recuerdan? es el LosFormatter) se puede leer tranquilamente el contenido del ViewState usando un simple deserializador. Una forma de averiguarlo es usando el ViewState Decoder de Fritz Onion, si lo usamos en nuestra página simple podremos ver algo un poco aterrador:

<?xml version="1.0" encoding="utf-16"?>
<viewstate>
  <Pair>
    <Pair>
      <String>-1616687229</String>
      <Pair>
        <ArrayList>
          <IndexedString>data</IndexedString>
          <String>hola mundo</String>
        </ArrayList>
      </Pair>
    </Pair>
  </Pair>
</viewstate>

Digo aterrador porque para algunos programadores paranoícos (sorry, no entro en esa categoría) podrian decir algo como “herejía, como es posible que el cliente pueda ver esa data ‘secreta’”. Bien, para satisfacer ese instinto de paranoia que llevan dentro solo hay que agregar a la meta-tag de página: ViewStateEncryptionMode=”Always”

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" 
    Inherits="WebApplication11._Default" ViewStateEncryptionMode="Always"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    </div>
    </form>
</body>
</html>

Listo, ahora no podran ver el “mensaje secreto”.

NOTA1: Eso no significa que deben guardar información sensitiva en el ViewState.

NOTA2: Aunque es posible leer el contenido del ViewState NO es posible enviar contenido modificado de regreso al server.

NOTA3: por casualidad revisando la documentación me topo con que para variar esta propiedad también puede ser modificada en el Web.Config

<configuration>
   <system.web>
      <pages ViewStateEncryptionMode="Always" />
   </system.web>
</configuration>

Disminuyendo el ViewState, Server Side State con Session

cristian — Fri, 19 Jun 2009 20:17:41 -0600

Creo que para estas alturas más de alguien tiene que haber pensado algo como: “Hey, si puedo controlar donde guardar el ViewState, porqué en vez de ‘comprimirlo’ y enviarlo al cliente no lo ‘guardo’ en el servidor?”

Pues claro que se puede, en la .Net Framework 2.0 se agregó una propiedad más a la System.Web.UI.Page llamado PageStatePersister que retorna un objeto de tipo PageStatePersister, este se utiliza en la ejecución de la cascada del runtime de asp.net para retornar el objeto encargado de persistir el ViewState (o sea, guardarlo o retraerlo). Cómo los desarrolladores de ASP.net siempren andan buscando un “shortcut” y a más de alguien se le debe haber ocurrido guardar el ViewState en la sesión del usuario (que por defecto se guarda en la memoria del AppPool en el servidor) existe ya un PagePersister conocido como SessionPageStatePersister, para usarlo basta con hacer lo siguiente:

using System;
using System.Web.UI;

namespace WebApplication8
{
    public partial class _Default : Page
    {
        protected override PageStatePersister PageStatePersister
        {
            get { return new SessionPageStatePersister(this); }
        }

        protected void Page_Load(object sender, EventArgs e)
        {
        }
    }
}

Listo, ahora nuestro ViewState no existe en la página sino en la sesión del usuario donde quiera que esta se este guardando (recuerdan? InProc? Session Server?). Hay que tener cuidado porque por defecto la sesión tiene una duración de 20 minutos y si se recicla el Application Pool no solo perdemos los datos de la sesión, sino también el ViewState. Otro problema es que el SessionPageStatePersister guarda una cantidad “fija” de elementos dentro del historial de la sesión, por defecto es de 9 items dentro del historial, esto lo podemos cambiar en el Web.config con la entrada sessionPageState

<system.web>
    <!-- otros elementos del system.web -->
    <sessionPageState historySize="20" />
</system.web>

Hey, un momento, eso indica que puedo usar el SessionStatePersister para crear mi propio storage server side del ViewState…… YEAH!!! exacto!!! pero eso será algo que no tocaré en esta serie de artículos, o quizás si, pero después :)

Saludos!

Debugeando bases de datos con Visual Studio

cristian — Fri, 19 Jun 2009 19:45:00 -0600

Hay algo poco conocido entre los usuarios de Visual Studio en general, lo increíble de sus herramientas de debugging (claro, nada con un WinDBG para debuggear, pero ese es otro tema!).

De hecho, muy pocas personas saben que Visual Studio tiene la capacidad de debuggear Procedimientos almacenados (Stored Procedures) y UDF (User Defined Functions) dentro de Visual Studio, yep, con “step into” y todo!

“Pure SQL Server Debugging”

Usando el Server Explorer podemos seleccionar el UDF o SP que queremos debuggear y haciendo click derecho sobre la función/sp objetivo le indicamos que “Step Into Function”

Nos presentará el conocido cuadro de ingreso de parámetros, ingresamos lo que queremos probar y voilá!

Si vemos cuidadosamente observaremos que aparecen las ya conocidas “debug tooltips” que nos muestran los valores de nuestras variables y parámetros locales (obviamente también podemos verlos en la ventana de Locals del Visual Studio). Con esta opción no necesitamos tener ninguna solución o proyecto abierto, simplemente tener la conexión desde el Server Explorer del Visual Studio. ¿Simple verdad?

SQL Server and Application Debugging

Otra opción es hacerlo desde dentro de nuestro proyecto de C# o VB, con esta opción en particular tenemos la posibilidad de agregar breakpoints a nuestros SPs o UDFs, simplemente agregamos el Breakpoint en el SP o UDF como estamos acostumbrados y le decimos al proyecto que habilite las opciones de debugging de SQL Server para ese proyecto en cuestión.

Aseguremonos también que la base de datos esta habilitada para Application Debugging, simplemente hagamos click derecho sobre la base de datos en cuestión en el Server Explorer y revisemos que aparezca algo así:

Done… ¿Aún más sencillo verdad?

Observaciones importantes

Visual Studio necesita correr en modo Administrador (o sea, en Windows Vista hay que decirle que “Run As Administrator”).
Cuando se trata de una instancia remota de SQL Server las cosas se ponen un poco más complicadas. SQL Server necesita correr bajo un usuario que pertenezca al rol sysadmin en el login de SQL Server.

Espero tengan un “happy debugging” :D

Disminuyendo el ViewState, reutilizando los cambios

cristian — Thu, 18 Jun 2009 09:45:00 -0600

¿Bueno, hasta el momento hemos aprendido un par de trucos y cosas no solo del ViewState, sino de ASP.net en general. Hemos comprimido, cambiado, guardado y reutilizado el ViewState de una página en específica, es cuando a nuestro precavido lector se le puede venir la siguiente pregunta: “¿Cómo reutilizamos nuestros cambios en las páginas?”

Realmente se me ocurren tres formas diferentes (aunque ahora que lo pienso hay 4, hablaremos de ella luego) de reutilizar nuestros cambios hechos en la página y pasarlos a toda otra multitud de páginas. Algunos de ellos pueden ser “asumibles” y otros usaremos técnicas no muy conocidas entre los usuarios de ASP.net.

Herencia

Bien, creo que esta era lógica, como recordaremos toda página de ASP.net es una “hija” de la clase System.Web.UI.Page, nuestros cambios han sido implementados como overrides de Page, ¿porqué no llamamos a nuestra clase con Overrides CompressedViewStatePage y la declaramos como abstract y a partir de ella cambiamos el resto de las páginas?. Quizás algo como esto:

Y bueno, cada vez que querramos utilizar nuestro sistema de ViewState comprimido en una página basta con decirle a nuestra página objeto que es de tipo CompressedViewStatePage y no de Page:

¿Simple verdad?, mmmm… Houston we got a trouble… si actualmente tenemos un proyecto con muchas páginas (algo sumamente común en asp.net webforms) tendríamos que ir página por página y hacer nuestros cambios, rayos, debe existir una forma más fácil.

The Browser File

Algo muy poco conocido de ASP.net es su capacidad para adaptar su página y hasta el markup de los controles dependiendo del browser del cliente, yep, eso es posible!.

Así como existen carpetas “especiales” como App_Data, App_Code y App_Theme, existe una carpeta poco conocida llamada App_Browsers, donde podemos crear lo que se le llama un “Browser definition file” que dependiendo del browser del cliente pudemos lograr un override general a nuestra página en cuestion y así manipular a nuestro antojo el comportamiento de la cascada.

Esto lo logra mediante el concepto de “adaptadores de renderizado”, que le indica a la framework en vez de la clase X usar la clase Y cuando un browser Z este presente (pura ecuación matemática!). Obviamente lo que debemos indicarle es que en presencia de “cualquier” browser simplemente utilice nuestra clase CompressedViewStatePage en vez de la clase Page, interesante y simple verdad? :D

En nuestro caso simplemente agregamos un App_Browsers folder a nuestro proyecto de “ViewState comprimido” y agregamos un nuevo “Browser File”, en su interior definimos que “por default” usaremos nuestra clase heredada de Page (CompressedViewStatePage) en vez de Page.

<browsers>
    <browser refID="Default">
        <controlAdapters>
            <adapter controlType="System.Web.UI.Page" 
                     adapterType="MyApplicaction.CompressedViewStatePage, MyApplication" />
        </controlAdapters>
    </browser>
</browsers>

Simple y efectivo!

Si quieres conocer un poco más acerca del Browser Definition File basta con revisar la ayuda de MSDN aquí y un interesante artículo de Jess Chadwick sobre como reemplazar controles con el App_Browser file.

Saludos

Visual Studio 2010 ¿que hay de nuevo?

cristian — Thu, 18 Jun 2009 09:22:41 -0600

Compañeros en .Net como mi amigo Carlos Lone, han hecho un par de webcasts acerca de las nuevas features de Visual Studio 2010, para aquellos que les gusta estar “en todas” y adelantarse a los acontecimientos, les dejo la lista de episodios de Channel 9 y su serie “10-4” con muchos videos sobre las nuevas features de VS2010 y .Net Framework 4.0

Aquí esta el link: Channel9 10-4 (Visual Studio 2010)