MSDN Blogs
  • WarNov Developer Evangelist

    Breve Historia del Framework .NET

    • 11 Comments

    Otra de las preguntas frecuentes que tengo por ahí generalmente de personas que aún tienen que trabajar con desarrollos .net de legado (versión < 4.0), es: cuáles son las ventajas de hacer el cambio, sobre todo para tratar de convencer a sus líderes, para migrar.

    Lastimosamente ocurre una situación bastante particular, y es que cada versión del Framework ha hecho su trabajo muy bien. Así que una vez se termina una aplicación en determinada versión del Framework, no se ve la necesidad de evolucionar. Pero luego nos damos cuenta de que empezamos a limitar las implementaciones avanzadas que podríamos hacer a las que sí tendríamos acceso con la última versión.

    Es por esto que escribo este post, en el que hago un recorrido por la historia del Framework para que podamos ver rápidamente de qué nos estamos perdiendo, de acuerdo a la versión del Framework que tengamos instalada.

    • .NET Framework 1.0:
      • Liberado el 13 de Febrero de 2002 para Win98, Me, NT 4.0, 2000 y XP. Su soporte terminó en Julio de 2007 y el soporte extendido en 2009.
    • .NET Framework 1.1
      • Publicada en Abril de 2003 junto con el segundo reléase de Visual Studio .NET (2003). Fue la primera versión incluida como parte de un sistema operativo (Windows Server 2003). Su soporte terminó en octubre de 2008 y el extendido termina en octubre de 2013 (así que mejor vayan pensando en migrarse).
      • Mejoras:
        • Los controles ASP.NET que en el 1.0 eran un Addon ahora vienen nativos.
        • Seguridad mejorada con Code Access Security para ASP.NET
        • Soporte nativo para ODBC y Oracle
        • Nacimiento del .NET Compact Framework
        • Soporte a IPV6
        • Cambios numerosos en las APIs.
    • .NET Framework 2.0
      • Liberado con Visual Studio 2005, SQL Server 2005 y BizTalk 2006. El primero en incluirse automáticamente en las instalaciones de SQL Server. Sin ningún Service Pack, fue la última versión en soportar Win98 y Me. Luego vino el SP 2 y con éste, fue la última versión en soportar Windows 2000.
      • Mejoras:
        1. Los fabulosos Generics
        2. Soporte para compilaciones de 64 bits
        3. Numerosos cambios en las APIs
        4. Integración con SQL Server: CLR Integration
        5. Inclusión del Runtime de .NET en aplicaciones nativas.
        6. Nuevos y mejorados controles de ASP.NET
        7. Controles de Datos con Data Binding automático.
        8. Soporte para Temas, Skins y Webparts.
        9. Nacimiento del .NET Micro Framework.
        10. Clases Parciales!
        11. Tipos “Nullable” (por ejemplo enteros a los que se les puede dar el valor de nulo)
        12. Métodos Anónimos!
        13. Iteradores
        14. Tablas de Datos
    • .NET Framework 3.0
      • Conocido en sus comienzos como WinFX fue liberado en noviembre de 2006 e incluyó un nuevo conjunto de APIs hechas en código administrado que son parte integral de Windows Vista y Windows Server 2008. También está disponible para Windows XP SP2 y Windows Server 2003. No hubo mayores cambios arquitectónicos. De hecho, se usa el runtime del Framework 2.0. Aquí tampoco hubo liberación de Compact Framework.
      • Mejoras:
        • Windows Presentation Foundation (conocido antes como Avalon)
        • Windows Communication Foundation (conocido como Indigo)
        • Windows Workflow Foundation
        • Windows CardSpace (Conocido antes como InfoCard).
    • .NET Framework 3.5

       

    .NET Framework

     

    • Vio la luz en noviembre de 2007 pero no es incluida en Windows Server 2008. Modifica el CLR fundamental sobre el que se venía trabajando (2.0) para agregarle los métodos y propiedades requeridas sobre todo para LINQ. Aquí sí se liberó el Compact Framework 3.5. El código fuente de esta versión fue parcialmente liberado para conocimiento público con fines de depuración.
    • Mejoras:
      • Nuevas características de lenguaje en C#3.0 y VB.NET 9.0
      • Soporte para árboles de expresiones y expresiones y métodos lambda
      • Extension Methods!
      • Tipos Anónimos con inferencia estática de tipo
      • LINQ!
      • Soporte a paginación en ADO.NET
      • API de sincronización de ADO.NET
      • API de I/O asincrónico
      • PNRP Resolver (Peer-To-Peer)
      • Wrappers Administrados para instrumentación y Active Directory
      • Motores de WCF y WF mejorados que permiten el manejo de POX y JSON en WCF y también exponer WF como servicio. De esta manera, los servicios WCF se pueden mejorar con persistencia nativa de WF!
      • Soporte para pipeline de HTTP y sindicación de feeds.
      • ASP.NET Ajax ya no viene como un addon sino nativo.
    • Service Pack 1:
      • Liberado en agosto de 2008.
      • Performance mejorado para WPF en un 20-45%
      • Agregado el Entity Framework y los ADO.NET Data Services.
      • Agregados dos nuevos assemblies: System.Web.Abstraction y System.Web.Routing: Esenciales para el funcionamiento del MVC Framework. Incluyó un conjunto de controles de VisualBasic que se habían descontinuado como el Line y el Shape, en un conjunto llamado “Visual Basic Power Pack”. Viene con Windows 7 y Windows Server 2008 R2.
    • .NET Framework 3.5 SP1 Client Profile
      • Nace como una versión reducida del Framework con solo 28MB de tamaño, ideal para clientes inteligentes que no requieren todos los 250 MB del Framework completo.

     

    framework-net

     

    En la mayoría de casos (Excepto cuando se trata de pasar del 1.0 0 del 1.1 a cualquier otra versión del Framework) El paso es transparente y la migración no es muy compleja. Sin embargo es claro que siempre hay temores en las migraciones y puede hacerse complicado comenzar a disfrutar de las características de la última versión. Sin embargo, nada como estar trabajando con ella, de manera que ya vamos a tener disponibles todas las últimas características y sobretodo disfrutar de todas las nuevas tecnologías que siempre se enfocan a la última versión.

    Así que si no tiene el Framework 4.0. Que está esperando?

  • WarNov Developer Evangelist

    Buenas Prácticas en Manejo de Excepciones .Net

    • 18 Comments

    Hace poco me preguntaron acerca de cómo se debería de abordar el manejo de excepciones para una aplicación grande.

    Me sentí agradado de que esa persona estuviera concientizada de que no es un tema que se puede dejar al azar y que hay que tener ciertos temas en cuenta.

    Básicamente, su duda era acerca de cómo capturar unificadamente todas las excepciones producidas en su aplicación; luego de alguna investigación, llegó a saber de Application.ThreadException; un evento al que se le puede poner un manejador y allí tomar las acciones necesarias. Sin embargo, personalmente no recomiendo esta solución. Por qué?

    1. La notificación de la excepción ocurre muy tarde: cuando se recibe la notificación, la aplicación ya no podrá responder a la excepción.

    2. La aplicación terminará abruptamente si la excepción ocurre en el hilo principal o en cualquier otro hilo que sea iniciado por código no administrado (el hilo principal de la aplicación obviamente es ejecutado por Windows – no administrado)

    3. No tenemos acceso a ninguna información valiosa acerca del error, excepto la excepción misma. No se podrán cerrar conexiones a bases de datos, hacer rollback de transacciones ni nada útil. 

    Así que mi recomendación es nunca basar el manejo de excepciones en los eventos Application.ThreadException ni AppDomain.UnhandledException. Ellos deben ser usados y existen como las redes de seguridad de los acróbatas; su función es la de hacer un registro de la excepción en algún mecanismo de log, para alguna examinación futura. Así que hay que darse la pela y manejar cada excepción en su sitio y actuar en concordancia.

    Esta última invitación conlleva a tener en cuenta otra serie de factores que generalmente se omiten cuando uno comienza a desarrollar “en forma”:

    1. El código metido entre try, catch se ejecuta muy lento. Consume muchos recursos. Así que sólo manejemos excepciones cuando realmente se necesite. Cuándo es eso?
    Las excepciones están construidas para manejar condiciones que no se pueden controlar con la lógica de la aplicación. Por ejemplo que se cae la conexión con el servidor, o que el disco está lleno, o que el hardware falló…
    Antes de lanzar excepciones por todo, fijémonos si realmente es necesario. Evitemos también poner mucho código en el try; solo afectemos con el try el código que realmente puede fallar. Por ejemplo es preferible:

    if (conn.State != ConnectionState.Closed)
    {      
       conn.Close(); 
    } 

    a:

    try
    {
            conn.Close(); 
    } 
    catch (InvalidOperationException ex)
    {
         Console.WriteLine(ex.GetType().FullName);
         Console.WriteLine(ex.Message);
    } 

    2. No emita Exception(). O es que eso le da mucha información?
    El framework .net tiene un número de excepciones que nos permite controlar argumentos y operaciones inválidas, timeouts, conexiones, overflows, etc. Usemos esas excepciones que realmente nos indican qué fue lo que sucedió.

    3. Use bloques try/finally. Recuerde que las instrucciones en el Finally siempre se ejecutan independientemente de si se produjo o no la excepción. Esto es muy útil para liberar recursos, cerrar conexiones, etc.

    4. Siempre use un catch para cada tipo de excepción que se pueda generar y ordénelos desde el más específico hasta el menos específico. Esto ayuda a identificar plenamente el error que se generó y no terminar con excepciones como: “Object reference not set to a instance of an Object”.

    5. Cuando cree excepciones propias del aplicativo, asegúrese de distribuir el Assembly a una ubicación compartida para todos los posibles dominios que tengan que ver con ellas.

    6. De acuerdo a como el mecanismo de excepciones funciona, es muy importante siempre que creemos excepciones propias, proveerlas al menos con los tres constructores de excepciones básicos.

    7. Siempre es recomendable usar las excepciones de .Net. Las personalizadas solo tendrán que ver con escenarios programáticos.

    8. Siempre se ha pensado que para las excepciones personalizadas se debería heredar de ApplicationException; sin embargo en la práctica se ha demostrado que no se agrega valor significativo y además se pierde cierto performance. Así que es mejor heredar siempre de Exception.

    9. Use mensajes gramáticamente correctos.

    10. Las excepciones pueden incluir propiedades. Estas propiedades pueden ser accedidas programáticamente para tomar acciones. Incluya información extra relevante en estas propiedades cuando sea útil.

    11. En vez de retornar null, lance excepciones en la mayoría de casos. Eso evita inconvenientes que a veces son difíciles de detectar. Evite también retornar códigos de error.

    Estas son solo unas pocas recomendaciones a la hora de manejar excepciones. Hay muchas más que se aprenden con el pasar de las líneas de código.

    Para finalizar, me parece importante mencionar también que igual existe un Application Block en Patterns And Practices para el manejo de Excepciones. Incluyéndolo en nuestras aplicaciones ya de por sí garantizaremos varias buenas prácticas; eso sí, usandolo tal y cual se explica en los lineamientos.

  • WarNov Developer Evangelist

    Cuentas de prueba de Windows Azure gratuitas por una Semana

    • 8 Comments

    Para que puedan probar todo lo que deseen en Windows Azure por una semana de manera totalmente gratuita y sin tarjeta de crédito, he creado este sencillo concurso en el cual los ganadores serán las primeras 15 personas en comentar este post, poniendo su usario en twitter que debe estar siguiendo a @msdevcol y gustarle la página de Microsoft Developers Colombia en Facebook.

    Los 15 ganadores tendrán una cuenta activa en Windows Azure desde hoy hasta el día 16 de Julio.

    Por mensaje directo les enviaré su usuario y password para que entren directamente por el Windows Azure Developer Portal.

    Recuerden que aquí encuentran todos mis artículos de Azure y que si tienen dudas, pueden formularlas como comentarios en este Post.

    A comentar!

Page 1 of 1 (3 items)